C语言多进程程序中基于信号通信的异常处理问题

我们的多进程程序采用信号机制安全终止子进程：当父进程遭遇malloc()、pipe()或fork()调用失败这类严重错误时，会向子进程发送信号，触发子进程终止并释放资源，以此避免子进程间依赖导致的不可预测行为。

但目前遇到偶发的主结构体Double Free问题：当某个子进程正在释放主结构体中的数组（遍历数组逐个释放元素的过程尚未完成）时，若收到父进程的终止信号，信号处理函数会直接释放主结构体并终止进程，导致数组前半部分已释放的元素被二次释放，触发Double Free。

已知free()并非异步信号安全函数，禁止在信号处理函数中调用。

核心问题 #

1. 若信号处理函数仅设置全局终止标志，检查该标志的合适准则是什么？
2. 有哪些安全且优雅的策略可以解决该Double Free问题？

我们初步考虑了两种方案，希望得到针对性分析：

方案分析与优化建议 #

方案1：信号处理函数仅设置全局终止标志，在常规流程中检查 #

这是信号安全的基础实现思路，无需“频繁无差别检查”，选对时机即可兼顾安全性与代码优雅性：

• 推荐检查时机：
  • 批量资源操作的间隙：比如遍历释放数组时，每释放若干个元素就检查一次标志；或者完成一个独立的资源操作单元后（如释放单个数组元素、完成一次数据处理循环）
  • 系统调用前：调用malloc()、pipe()、fork()这类可能阻塞或失败的系统调用前，插入标志检查——这类节点本身就是程序的关键控制点，不会过度侵入代码
• 关键注意点：全局标志必须定义为volatile sig_atomic_t类型，确保信号处理函数对标志的修改能被主流程立即感知，同时符合C标准的信号安全要求

方案2：释放指针后立即置为NULL #

该方案能降低Double Free的概率，但存在明确的风险：free(ptr)与ptr = NULL是两条独立的CPU指令，信号完全可能在这两条指令之间触发，此时指针仍指向已释放的内存区域，若后续清理逻辑尝试释放该指针，依然会触发Double Free。因此仅靠这种方式无法彻底解决问题。

更安全优雅的补充策略 #

• 原子状态标记：为主结构体或关键资源设置原子状态（如enum { RESOURCE_ALIVE, RESOURCE_TERMINATING, RESOURCE_TERMINATED }），信号处理函数仅将状态置为RESOURCE_TERMINATING；主流程在执行资源释放操作前先检查状态，若已进入终止状态则直接跳过当前释放逻辑，转而执行统一的安全退出流程
• 统一清理入口：设计一个异步信号安全的终止触发逻辑，信号处理函数仅设置原子终止标志；主流程检查到标志后，调用统一的资源清理函数——清理函数中先标记资源为“待清理”，再按固定顺序释放资源，从根源避免重复清理
• 临界区信号屏蔽：在执行批量资源释放的临界代码段（如遍历释放数组的循环），临时屏蔽终止信号，完成这段操作后再恢复信号接收。注意屏蔽信号的时间要尽可能短，避免影响进程响应终止的及时性

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