SIGCONT 的默认操作是否在首次处理任何挂起的未阻止信号之前或之后恢复已停止进程的执行?

SIGCONT 的默认操作是否在首次处理任何挂起的未阻止信号之前或之后恢复已停止进程的执行?

POSIX系统接口规范说:

默认操作为SIGCONT是在进程停止的位置恢复执行,首先处理任何待处理的未阻塞信号。

这里的“之后”是什么意思?不应该是“之前”吗?有一些例子可以说明它的含义吗?

APUE 也有类似的情况:

由于当父进程终止时进程组将成为孤立进程,因此 POSIX.1 要求向新孤立进程组中停止的每个进程(就像我们的子进程一样)发送挂断信号 ( SIGHUP),然后发送继续信号 ( SIGCONT)

这使得孩子能够继续,处理挂断信号。挂起信号的默认操作是终止进程,因此我们必须提供一个信号处理程序来捕获该信号。因此,我们期望 sig_hup 函数中的 printf 出现在 pr_ids 函数中的 printf 之前。

“之后”不应该是“之前”吗?

SIGCONT和 的顺序SIGHUP孤儿 Linux 进程组在上面的两句话中似乎建议“之前”而不是“之后”,或者我误解了它:

SIGHUP在子进程恢复执行之前,无法传递该消息。当进程停止时,除 SIGCONT和之外的所有信号传递都会暂停SIGKILL

所以,确实SIGHUP先到达,但是它无法被处理,直到SIGCONT 唤醒进程执行。

谢谢。

当多个信号到达一个进程时,处理这些信号的进程之间的顺序是什么?

答案1

不,是之后的意思。关键是“恢复执行在进程停止的地方”。

首先进行信号处理,并且然后执行仍在继续。

答案2

信号.c 符合 POSIX 1b 标准的信号内核代码

在 上进行搜索SIGCONT。您将看到,当SIGCONT遇到该信号时,代码就会查找待处理的信号。

相关内容