为何在C语言信号处理期间仅一个SIGINT被排队，其余被忽略？

嘿，这个问题我当初刚啃Unix信号的时候也踩过坑！其实核心原因就在于标准信号（比如SIGINT）的“非排队”特性，但它有个“待处理标记”的小细节，咱们一步步拆解：

首先，当你按下第一次Ctrl+C触发SIGINT时，内核会调用你注册的信号处理函数，同时自动把SIGINT加入当前进程的信号掩码——简单说就是，在这个处理函数运行期间，同类型的SIGINT会被暂时“挡住”，不会立刻触发新的处理。

但这里关键来了：如果在处理函数运行时，你又发送了同类型信号，内核不会像实时信号那样排队记录每一次，只会做一件事：检查这个信号有没有被标记为“待处理”。如果还没标记，就标记一次；如果已经有标记了，直接忽略后续的同类型信号。

对应你说的场景：

• 第一次Ctrl+C：触发处理函数，SIGINT被屏蔽，处理中（sleep 3秒）。
• 第二次Ctrl+C：内核收到，发现SIGINT被屏蔽且还没待处理标记，就打上标记。
• 第三次、第四次Ctrl+C：内核收到后，发现已经有SIGINT的待处理标记了，直接跳过，不做任何记录。

等第一个处理函数跑完，内核会自动把SIGINT从信号掩码里移除，这时候它检查到有一个待处理的SIGINT，就立刻触发第二次处理函数。而后面那两次因为没被记录，自然就被忽略了。

补充个小知识点：只有实时信号（SIGRTMIN到SIGRTMAX）才支持排队，每收到一次就会记录一次，处理的时候按顺序逐个触发。但SIGINT属于传统的标准信号，没有这个待遇。

如果你的需求是要捕捉到每一次SIGINT，要么改用实时信号，要么可以在信号处理函数里用一个volatile sig_atomic_t类型的变量来计数（这个类型是异步安全的，适合在信号处理里用），每次收到信号就把计数加1，然后在主程序里定期检查这个计数来处理——不过要注意主程序里的循环不能阻塞太死，不然可能错过处理时机。

内容来源于stack exchange