为什么我们通常会忽略SIGCHLD

Question

我正在研究信号并通过这个链接

https://en.wikipedia.org/wiki/Child_process#cite_note-1

这就是它所说的：“SIGCHLD信号在被中断后被中断或恢复时被发送到子进程的父进程。默认情况下，信号被忽略”

我们有没有理由忽视SIGCHLD。

Answer 1

尝试生孩子，你就会明白为什么有时你必须忽略SIGCHLD才能保持理智:)。

除了笑话之外，所有这一陈述意味着POSIX系统不会为SIGCHLD定义默认信号行为，而不是忽略它。将其与SIGINT，SIGTERM等进行比较，默认行为可能是终止进程。

请参阅linux上的man 7 signal以获取所有信号的列表，所有默认处理程序以及信号映射 - >默认处理程序。

忽略SIGCHLD通常是有道理的，因为您可以从waitpid了解您需要了解的所有内容。

Answer 2

即使我的回答来得太晚，对于想知道需要SIGCHLD的原因以及为什么忽略它的好奇者来说，这可能还是有帮助的。让我们听听我的故事。

我参加了一个项目，在该项目中，我们正在流播扩展名为.pls，.m3u或仅IP:Port的在线广播电台。每个站都是我们的频道。有两个{– {3}}和potentiometer-可以顺时针或逆时针旋转（切换）。前者用于调节收音机的音量，后者同样用于改变频道。我正在使用通过终端工作的媒体播放器，因此它也是另一个过程。同样，我正在使用rotary encoder，它也是另外一个过程，可在一段时间无限循环内突然调整音量。在主要过程中，我创建了两个过程。要更改频道，我选择发送SIGKILL信号终止播放器进程，该进程可能会播放选定的电台以进入新频道并在父频道中wait()。 wait()的用法在这里很合适，因为我在等待之前就杀了他。它会立即返回而不会阻塞。在音量调节器一侧，它可以工作到关闭无线电设备。它的过程正在无限循环中运行。

  

那么，如果我选择等待其父进程等待音量调节器进程，会发生什么？

由于音量调节器进程将永远不会返回，因此主进程将永远阻塞。取而代之的是，我选择显式处理，但以忽略的方式处理。 为什么？，因为我不在乎它何时终止或它的返回值是多少。我只关心终止后，我不希望孩子变成僵尸。我只想在孩子退出时立即收获它，并且不阻塞主流程。

  

为什么我们通常会忽略SIGCHLD？

如果（如上述示例所示）信号处理程序除了调用waitpid之外没有执行任何其他操作，则可以使用替代方法。将SIGCHLD处理程序设置为SIG_IGN将导致自动获取僵尸进程。

别忘了这样做，需要显式调用sigaction()来调用SIG_IGN。