多线程场景下处理工作线程取消点是否需阻塞主线程SIGINT？

不需要必须在主线程阻塞信号才能让工作线程的pselect正常响应中断。但你必须通过全局阻塞+定向放行的方式，保证信号的投递目标是预期的工作线程，否则多线程场景下的信号投递是完全随机的，必然会出现你碰到的这类异常。

• Linux内核对多线程进程的信号投递有明确规则：进程注册了捕获处理的信号，不会绑定到某个固定线程。内核会从当前所有未阻塞该信号的线程中，随机挑选一个完成投递。
• 你碰到的异常流程本质是：程序启动后，卡在thread::join()上等待的主线程、跑pselect的工作线程，都没有屏蔽SIGINT。按下Ctrl+C时，内核随机选中了处于futex等待状态的主线程接收信号，工作线程上的pselect根本收不到中断，自然会一直挂起，不会返回EINTR。
• 你观察到“在主线程阻塞SIGINT就恢复正常”，不是因为主线程阻塞这个动作有特殊作用，而是这个操作刚好让整个进程里唯一未屏蔽SIGINT的线程，就只剩跑pselect的工作线程，内核没有别的可选投递目标，只能把信号发给工作线程，才触发了你预期的中断返回流程。

完全不需要依赖“只阻塞主线程”的取巧写法，按照POSIX规范的标准流程操作即可，从根源上避免随机投递问题：

1. 程序启动最早期，在创建任何工作线程之前，通过pthread_sigmask()全局阻塞SIGINT、SIGTERM这类需要捕获的信号。由于新建线程会完整继承创建者的信号掩码，后续所有创建的工作线程，默认都会阻塞这些信号，内核根本没有随机投递的选择空间。
2. 当负责事件循环的工作线程（即运行pselect/epoll_wait做IO复用的线程）启动后，再在这个线程内部，通过pthread_sigmask()解除对目标信号的阻塞。此时整个进程里就只有这个专属的事件线程能收到对应信号，内核的投递结果是100%确定的。

• sigaction()注册的信号处理器是进程级全局配置，和注册时所在的线程无关：只要任何一个线程收到这个信号，就会执行同一个处理器逻辑。
• “只在主线程阻塞信号”属于脆弱的偶发正常实现：如果后续新增其他工作线程时，忘记给这些线程加对应的信号屏蔽，那么下次触发信号时，内核就可能随机把信号投递给这些未屏蔽的新线程，打断它们正在执行的系统调用，引发不可预期的逻辑错误。

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