![为什么 Linux 内核不先向包含已停止进程的新孤立进程组发送 SIGCONT,然后再发送 SIGHUP?](https://linux22.com/image/145222/%E4%B8%BA%E4%BB%80%E4%B9%88%20Linux%20%E5%86%85%E6%A0%B8%E4%B8%8D%E5%85%88%E5%90%91%E5%8C%85%E5%90%AB%E5%B7%B2%E5%81%9C%E6%AD%A2%E8%BF%9B%E7%A8%8B%E7%9A%84%E6%96%B0%E5%AD%A4%E7%AB%8B%E8%BF%9B%E7%A8%8B%E7%BB%84%E5%8F%91%E9%80%81%20SIGCONT%EF%BC%8C%E7%84%B6%E5%90%8E%E5%86%8D%E5%8F%91%E9%80%81%20SIGHUP%EF%BC%9F.png)
APUE 说
由于当父进程终止时,该进程组将成为孤立进程,并且该进程组包含已停止的进程,因此 POSIX.1 要求向新孤立进程组中的每个进程发送挂起信号 (SIGHUP) 其次是继续信号(SIGCONT)。
内核在SIGHUP之后发送SIGCONT,但是进程在对SIGHUP起作用之前被SIGCONT唤醒。那么为什么Linux内核不在SIGHUP之前发送SIGCONT呢?
谢谢。
相关但未回答SIGCONT 的默认操作是否在首次处理任何挂起的未阻止信号之前或之后恢复已停止进程的执行?
我没有回答我的问题。
答案1
您不仅回答了您的问题,您最后添加的链接也回答了您的问题。
当进程停止时,所有信号处理都会停止,但 SIGCONT 和 SIGKILL 除外 - 实际上它们是由操作系统处理的。
这意味着 SIGHUP 只能在进程恢复后处理,这种情况发生在接收并处理 SIGCONT 时,因此,即使您发送 SIGHUP 后跟 SIGCONT,它们也会以相反的顺序处理。
现在,实际上,内核在处理 SIGCONT 和处理 SIGHUP 之前发送 SIGHUP 将导致进程在处理 SIGCONT 和处理 SIGHUP 之间完成的工作更少,因为第二个已经排队等待处理。