关于SIGCHLD的不排队,丢弃的问题

flw

塑料袋兄弟，以您目前的水平，还不适合在 ChinaUnix C/C++ 版回答别人的问题。希望您在这一点上有足够的自知之明，否则只会毒害别人，并没有什么好处。
哦，忘了说了，Confirming to POSIX.1，SIGCHLD 的默认行为是 ignore the signal。

linternt

这个问题说了这么多，我觉得还是针对性问题做一些处理吧。
原理和应用要各自对待才是。

观注一下高手的精彩回答

ccjjhua

建议有重大争议的论题，能有高手作最后的总结陈词。以后看话题的时候只要看最后的发言就知道答案了。省时间。

ccjjhua

我觉得父进程要等待子进程结束的信号，不仅仅是为了回收它 ，更重要的是有些应用需要父进程在子进程退出的时候做些相应的操作。如果只是为了回收，父进程可以忽略该信号。当子进程退出时，父进程是有可能接受不到该信号，就是“丢失”的情况发生了，如果只是为了不让有僵尸进程发生，父进程可以继续等待下一个（其他子进程产生的退出信号）信号，就可以把原来的子进程进行回收，但如果父进程需要针对该子进程做些特别的操作，就不可能完成了。不知道我说的对不对。

[ 本帖最后由 ccjjhua 于 2006-9-20 10:54 编辑 ]

linternt

原帖由 ccjjhua 于 2006-9-20 10:48 发表
我觉得父进程要等待子进程结束的信号，不仅仅是为了回收它 ，更重要的是有些应用需要父进程在子进程退出的时候做些相应的操作。如果只是为了回收，父进程可以忽略该信号。当子进程退出时，父进程是有可能接受不到 ...

说的对，呵呵，高手

zleil

原帖由 flw 于 2006-9-15 17:20 发表
根本就不需要找回来！
好比有五个进程，
不妨分别称为 p1 p2 p3 p4 p5，
一开始 p1 结束了，发了一个 SIGCHLD(s1)，
这时父进程可能空闲了，于是开始处理这个信号，假设处理的过程中 p2 又结束了，又发了一个 SIGCHLD(s2)，
这时候已经有两个信号了（一个正在处理，一个待处理），这时如果 p3 又结束了，那么它发的那个 SIGCHLD(s3) 势必会丢失，
丢失了怎么办？
没关系，因为那个信号处理函数是个循环嘛，
所以 while(waitpid()) 的时候，会把 p1 p2 p3 都处理的。
即使是很不幸，因为十分凑巧的原因，p3 没有被回收，导致变成僵尸进程了，也没关系，
因为还有 p4 p5 嘛，等到 p4 或者 p5 结束的时候，

也就是所有被阻塞的SIGCHLD信号都是被一个待处理的SIGHLD信号阻塞，对不对？
这样，所有丢失信号SIGCHLD对应的僵死进程将被那个待处理的SIGHLD信号的响应代码回收，因为响应代码里有循环。对不对？

所以，

即使是很不幸，因为十分凑巧的原因，p3 没有被回收，导致变成僵尸进程了，也没关系，
因为还有 p4 p5 嘛，等到 p4 或者 p5 结束的时候

这种情况下，还是由P2产生的SIGCHLD信号的响应处理过程来回收P3僵死进程。flw看看是不是这样？

yuanyawei

原帖由 ccjjhua 于 2006-9-20 10:48 发表
我觉得父进程要等待子进程结束的信号，不仅仅是为了回收它 ，更重要的是有些应用需要父进程在子进程退出的时候做些相应的操作。如果只是为了回收，父进程可以忽略该信号。当子进程退出时，父进程是有可能接受不到 ...

以前作一个定时器时（秒）时，在大量任务进程同时结束时出现过这种丢信号的情况，原设计在接受到SIGCHLD信号后父进程马上做了些处理，但不到SLEEP(5)这么长，在不考虑极端的情况下，我是这么做的。处理信号的工作尽量简单化，我只是把它加入到一个链表里暂存，在父进程闲时才去处理。当时还是用的2.4的内核，应该是父进程处理时间过长导致的问题，用子进程自己记录ID到消息队列或共享内存里的方法也是可以的，但我不能保证我的子进程是否会core，那样就麻烦了。顺便补充一句，用在linux下丢信号的代码在aix4和hpux10下没有发现类似现象，但可能是配置高的原因，所以我还是更新了，也没有具体去测试aix和hp下sigchld是否排队？

googleboy

好帖子，希望高手们能继续。

aaaaal

继续关注

柳五随风

单纯用waitpid处理，存在p1~pn，当pn~pm的SIGCHLD丢失的时候，不能捕获child processes的状态的问题，在有些环境下（比如QT/QProcess）里面要求必须处理，不能忽略，那么一半采用的就是上面有人说的K-Queue的办法。
顺便问问，那位有在QT3.11上碰到过大量QProcess crash的问题？