UNIX信号通信中收到pid 0信号的异常问题排查

1. 来自pid 0的信号本质：进程组广播或内核占位信号 #

在macOS（基于BSD）系统中，不存在真正的pid 0用户进程（pid 0是内核调度进程，不会主动发信号给用户进程）。你收到的“pid 0”信号，其实是以下两种情况：

• 当进程调用kill()向一个不存在的pid发送信号时，BSD内核不会直接丢弃，而是将这个信号转化为向进程组0发送的广播信号，此时信号的sender pid会被标记为0。
• 当进程的信号队列溢出时，内核会发送一个占位信号（sender pid 0）来表示有信号丢失，避免进程完全无法感知异常。

2. 通信失败与pid 0信号的触发场景 #

你的逐字符传输逻辑依赖“客户端发信号→服务端确认→客户端发下一个”的同步流程，但UNIX信号本身是不可靠的：

• 最初未用静态变量存客户端pid时，服务端可能在接收信号时存在竞态条件（比如多次接收信号时，客户端pid被覆盖或读取错误），导致服务端向无效pid发送确认信号，触发内核生成pid 0的广播信号。
• 即使加了usleep，高频率的信号发送仍可能导致信号队列溢出，内核用pid 0信号提示信号丢失，这也是为什么你随机收到这类信号。

3. 服务端存静态pid后仍有pid 0信号，但过滤会挂起的原因 #

• 存静态pid解决了服务端向无效pid发信号的问题，但信号队列溢出的风险仍存在——当传输100字符的大字符串时，短时间内的信号收发可能填满信号队列，内核还是会生成pid 0的占位信号。
• 过滤pid 0信号会导致挂起，是因为你可能误过滤了真正的确认信号，或者当实际的确认信号因队列溢出丢失后，客户端一直在等待确认，没有后续信号触发继续执行。

4. 额外的macOS特性影响 #

macOS的信号实现与Linux有差异：Linux下信号队列溢出会直接丢弃新信号，而BSD系会用pid 0的信号来通知进程。同时，macOS对信号的发送优先级、队列长度的限制更严格，大字符串传输时更容易触发队列溢出。

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