Boost.Asio cancellation_signal协程取消用法及替代方案咨询

参考代码片段 #

template<typename CompletionToken>
boost::awaitable<int> async_op(CompletionToken) {...}

boost::asio::cancellation_signal cancel_signal;
...
auto value = co_await async_op(boost::asio::bind_cancellation_slot(
    cancel_signal.slot(), // 原代码此处cancel_token为笔误，已修正为对应声明的cancel_signal
    boost::asio::use_awaitable));
...

// 触发全量取消
cancel_signal.emit(boost::asio::cancellation_type::total);

问题1：上述用法是否是取消支持取消能力的协程的正确、最基础实现模式？ #

是，这是Boost.Asio中主动取消可取消协程的标准基础实现模式。
核心逻辑是通过bind_cancellation_slot将外部取消信号的监听槽绑定到异步操作的完成令牌上：调用cancellation_signal::emit发送取消请求后，信号会沿着异步操作链传递，所有原生支持取消的Asio组件（比如socket读写、定时器操作）收到信号后会立即终止执行，返回boost::asio::error::operation_aborted错误码，让挂起的协程恢复执行。
使用该模式需要满足两个必要前提：

• 调用的async_op本身实现了取消信号的响应逻辑，自定义异步操作如果没有读取、处理取消状态，哪怕发送信号也无法终止操作
• cancellation_signal的生命周期必须长于绑定的异步操作的整个执行周期，否则会触发悬空引用的未定义行为

问题2：实现相同协程取消效果是否存在其他方式？无法直接访问对应cancellation_signal实例时如何取消？ #

存在多种成熟的取消方案，不需要手动持有独立的cancellation_signal实例也能完成取消，常见方案如下：

• 利用协程自带的层级取消机制
  每个boost::awaitable协程启动时都会自动关联独立的取消状态，不需要手动创建cancellation_signal。协程内部可以通过co_await boost::asio::this_coro::cancellation_state获取当前取消状态，父协程触发取消时，所有派生的子协程都会自动收到取消信号，不需要逐个给异步操作绑定信号槽。如果需要从协程外部触发，只要持有对应协程的句柄，就可以通过协程关联的取消通道发送请求。
• 使用封装好的超时取消绑定器
  Asio内置了cancel_after、cancel_at两个便捷适配器，不需要手动管理信号对象，传入超时时间/时间点后，框架会自动创建内部信号，超时后自动发送取消请求，适合接口超时场景，写法示例：

  // 该异步操作超过3秒未完成就自动取消
  auto value = co_await async_op(boost::asio::cancel_after(std::chrono::seconds(3), boost::asio::use_awaitable));
  

• 调用IO对象自带的cancel方法
  所有Asio原生IO对象（tcp::socket、steady_timer等）都内置了cancel()接口，调用后会直接终止该对象上所有挂起的异步操作，不需要提前绑定取消槽。如果你拿不到之前绑定的cancellation_signal实例，只要能访问异步操作绑定的IO对象，直接调用其cancel()方法就能达到完全一致的取消效果。
• 通过执行上下文批量取消
  如果需要批量终止多个协程/异步操作，可以直接调用执行上下文的停止接口，比如io_context::stop()、thread_pool::stop()，调用后所有跑在该上下文上的未完成异步操作都会被触发取消，适合服务关停、任务批量终止的场景。

内容的提问来源于stack exchange，提问作者Viktor Khristenko