应使用静态std::stop_source配合信号处理器，确保所有线程共享同一停止源并正确绑定token，同时保证std::stop_callback生命周期覆盖全程，避免在信号上下文中析构或执行阻塞操作。
如果您希望在接收到操作系统信号（如SIGINT、SIGTERM）时触发多个线程的协作式取消，但std::stop_callback未执行或仅在单一线程响应，则问题通常源于信号处理与stop_source生命周期不匹配、回调对象提前析构，或stop_token未正确绑定至外部共享源。以下是解决此问题的步骤：
一、使用静态std::stop_source配合信号处理器
该方法确保信号处理函数能安全调用request_stop()，且所有工作线程通过同一token监听停止请求。信号处理器必须是async-signal-safe，而std::stop_source::request_stop()满足该要求。
1、在全局作用域声明static std::stop_source g_stop_source；
2、定义信号处理函数，内部仅调用g_stop_source.request_stop()；
立即学习“C++免费学习笔记（深入）”；
3、注册信号处理器：signal(SIGINT, signal_handler)和signal(SIGTERM, signal_handler)；
4、各工作线程构造时传入g_stop_source.get_token()，并在其中注册std::stop_callback；
5、确保std::stop_callback对象生存期覆盖整个程序运行周期，例如定义为全局变量或main函数内局部变量（在std::jthread启动前声明）。
二、将信号转换为std::jthread可响应的停止事件
该方法避免直接在信号处理器中执行复杂逻辑，而是借助std::jthread的自动join与request_stop机制，将信号捕获转为对线程控制流的间接干预。关键在于使信号处理器仅触发外部stop_source，而非操作线程私有token。
1、声明独立的std::stop_source sig_stop；
2、创建专用信号接收线程：std::jthread sig_thread([&sig_stop]{ sigwait_for_signal(sig_stop); })；
3、在sigwait_for_signal函数中，使用sigwait()阻塞等待SIGINT/SIGTERM，并在收到后调用sig_stop.request_stop()；
4、其余业务线程均使用sig_stop.get_token()构造std::stop_callback；
5、确保sig_stop对象生存期长于所有依赖它的std::stop_callback实例。
三、通过管道或eventfd实现信号到stop_source的异步通知
该方法绕过信号处理器的限制，采用文件描述符就绪机制，在主线程中轮询信号到达事件，从而在安全上下文中调用request_stop()。适用于需规避信号中断系统调用或避免信号处理函数中调用非async-signal-safe函数的场景。
1、创建匿名管道或eventfd（Linux）；
2、在信号处理器中仅执行write(pipe_fd[1], &sig, sizeof(sig))，该操作是async-signal-safe；
3、启动专用通知线程，使用poll()或epoll_wait()监听pipe_fd[0]；
4、当读到信号数据时，在该线程中调用外部std::stop_source::request_stop()；
5、所有业务线程绑定该stop_source的token，并确保std::stop_callback对象不早于该线程析构。
四、避免std::stop_callback在信号上下文中被误销毁
该方法聚焦生命周期管理，防止因作用域提前结束导致回调对象不可达。std::stop_callback是RAII类型，析构即注销，若其位于信号处理相关lambda或栈帧中，极易在信号到达前失效。
1、禁止将std::stop_callback定义在信号处理回调lambda内部；
2、禁止在std::jthread构造的lambda参数中声明std::stop_callback局部变量；
3、将std::stop_callback声明为与main函数同作用域的静态变量或命名空间作用域变量；
4、若使用类封装，将其作为类的成员变量，并确保该对象生存期覆盖整个运行过程；
5、验证方式：在回调函数内写入日志并检查是否实际执行，确认对象未提前析构。
五、确保回调执行环境满足无锁与轻量约束
该方法防止回调本身成为取消路径瓶颈。std::stop_callback执行于调用request_stop()的线程上下文（可能是信号处理线程或通知线程），若其中执行阻塞或耗时操作，将延迟所有线程的清理响应。
1、禁止在回调中调用close()、write()、std::mutex::lock()或std::this_thread::sleep_for()；
2、禁止在回调中访问可能已被析构的栈变量或局部std::ofstream引用；
3、仅执行std::atomic
4、清理逻辑应移出回调，改由工作线程主循环检测token.stop_requested()后主动执行；
5、多个回调绑定同一token时，不依赖执行顺序，各自独立完成其职责。
