信号中断时释放共享内存答案

【问题标题】：Free shared memory on signal interrupt信号中断时释放共享内存
【发布时间】：2012-05-03 12:10:48
【问题描述】：

我正在用 C 语言编写一个程序，并且正在创建几个使用 POSIX 共享内存的子进程。现在我正在尝试处理程序被 SIGINT 等信号中断的情况。我知道，我需要安装信号功能，由于代码不一致，直接在信号处理程序中释放资源并不好，因此只需切换布尔标志即可。同时我的主要代码是循环直到标志被切换。

所以它是这样的：

 bool signal_interrupt = false;     

 void sig_handler(int sig_num)
 {
   signal_interrupt = true;
 }

 int main(void)
 {
   while (!signal_interrupt)
   {
     /* code, arguments processing, functions calling...*/
     signal_interrupt = true;
   }
 }

我的问题是我不知道如何在程序的某些功能中释放资源。函数的代码是否应该与主函数中所示的循环相同？程序如何对信号中断做出反应？它从当前函数返回到主函数，如果找到信号函数，它的处理程序会被调用吗？感谢您的任何建议，我真的很想了解这一点。

【问题讨论】：

当你的程序接收到信号时，它会取消当前的系统调用并调用信号处理程序。在您的信号处理程序完成后，您的程序将在被中断的系统调用之后返回到下一个系统调用。

标签： c signals shared-memory

【解决方案1】：

哦，是的，共享内存等外部资源确实需要释放。

但是，从进程的角度来看，系统调用是原子的，因此从信号处理程序执行它们没有问题。只需调用外部资源析构函数然后退出。（不用担心调用 free(3)。）

【讨论】：

1.他正在使用共享内存，因此操作系统不会释放它。 2. 最好在退出时释放所有资源，因为使用 valgrind 跟踪内存泄漏要容易得多。
不，应用程序应该结束。问题是使用 shm_open 和信号量创建的共享内存留在 /dev/shm
@strkol，好吧，关于外部资源，你是对的。然而，对于那些，在信号处理程序中执行系统调用没有问题。通常的建议是避免malloc() 和free(). 并在退出之前调用free(3) 有一些真正的负面影响，并且在C++ FAQ 中特别不鼓励。此处已在 SO 上进行了详细讨论，并且存在不同的意见。
@DigitalRoss：在信号处理程序中只允许您做几件事。通常的建议是 - 您只能更改 sig_atomic_t 类型变量的值并调用异步信号安全函数。或者使用 epoll + eventfd 并做任何你想做的事情:)
我们在这里混合了 ISO C 和 Posix 限制。因为正在清理的 API 是 Posix，所以使用更宽松的 Posix 限制似乎是合理的。 ISO C 对更改任何内容的严格限制只是为了允许寄存器缓存和其他优化，并在共享数据结构操作周围有效地插入障碍。如果他不返回程序没有那很重要。