Linux C环境下线程池设计中I/O与控制类任务实现方案咨询

你提到的信号/信号定时器方案不是当前场景的最优选择，信号机制本身存在递送逻辑不可控、信号处理函数操作限制多的问题，很容易引入死锁、异步安全类问题，有更稳定易维护的实现方案，具体如下：

I/O类任务适配方案 #

• 核心思路：用独立的I/O监控线程 + epoll/poll多路复用机制实现就绪事件监听，完全规避信号使用
• 具体实现：
  1. 所有I/O类任务关联的文件描述符（串口、TCP socket等）统一设置为非阻塞模式
  2. 启动一个专用监控线程，持续调用epoll_wait监听所有注册的I/O文件描述符的可读/可写/错误事件
  3. 当监控到某fd就绪时，将对应I/O处理逻辑打包为任务，推入线程池的工作队列，由线程池worker线程执行实际的读写、业务处理操作
• 优势：逻辑清晰无异步安全风险，支持高并发I/O场景，和你已有的事件驱动任务的调度逻辑完全兼容，不需要修改线程池核心逻辑

控制类（定时运行）任务适配方案 #

可以选择两种成熟方案，均不需要使用信号机制：

方案一：复用I/O监控逻辑（推荐，适合同时存在大量I/O和定时任务的场景） #

• 用timerfd_create系统调用创建定时器，获得关联的文件描述符，按你的定时需求（比如每秒20次即50ms间隔）设置定时器参数
• 将timerfd的文件描述符注册到上述I/O监控线程的epoll实例中，定时器超时会触发该fd的可读事件
• 监控线程监听到timerfd就绪后，将对应定时任务推入线程池工作队列即可；如果是周期性任务，不需要重新创建timerfd，读完fd的超时计数后会自动重置等待下一次超时

方案二：独立定时调度线程（适合定时任务规则复杂、和I/O逻辑解耦的场景） #

• 启动一个专用的定时调度线程，维护一个按触发时间升序排列的定时任务队列（可使用小顶堆实现，取队首即可获得最近要触发的任务）
• 调度线程每次取出队首任务的触发时间，计算当前时间到触发时间的间隔，调用nanosleep/clock_nanosleep休眠对应时长
• 休眠结束后将触发的任务推入线程池工作队列；如果是周期性任务，计算下一次触发时间后重新插回定时任务队列即可

信号方案的问题说明 #

你最初考虑的信号/信号定时器方案存在以下不可忽视的缺陷：

• Linux下默认信号会递交给进程内任意未屏蔽该信号的线程，无法保证在指定线程执行回调，逻辑可控性差
• 信号处理函数仅允许调用异步信号安全的函数，若在回调中操作线程池的任务队列（通常队列会用互斥锁、条件变量做同步），很容易触发死锁、内存访问错误等问题
• 信号递送优先级高，会打断正常线程的执行，容易引发不必要的性能波动

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