为何忽略SIGCONT信号仍会让进程继续运行？

测试代码与执行过程 #

忽略SIGCONT的测试代码 #

int main() {
    signal(SIGCONT, SIG_IGN);
    while(1);
}

执行流程 #

> ./main &
[1] 25093
> kill -STOP 25093

[1]+  Stopped                 ./main
> ps -aux | grep 25093
xxx    25093 98.6  0.0   2488   872 pts/8    T    18:23   0:20 ./main
> kill -CONT 25093
> ps -aux | grep 25093
xxx    25093 52.1  0.0   2488   872 pts/8    R    18:23   0:28 ./main

问题解答 #

1. SIGCONT仍让进程恢复运行，是否意味着SIGCONT的处理程序仅为“副作用”？ #

不是。SIGCONT的核心设计目标就是恢复处于停止状态的进程，这是该信号的固有内核行为，和用户注册的信号处理函数（包括SIG_IGN）完全分离。

Linux内核处理SIGCONT时，会优先执行恢复进程的操作——不管用户是否忽略这个信号，只要进程处于TASK_STOPPED或TASK_TRACED状态，内核都会先把进程拉回运行状态，再处理用户定义的信号逻辑（比如忽略）。你测试中进程恢复运行，正是这个强制内核逻辑的结果，和处理程序的“副作用”无关。

2. SIGCONT何时让进程恢复运行？进程何时被重新放入调度队列？ #

进程恢复运行并加入调度队列的操作，发生在发送SIGCONT的kill系统调用执行过程中，是内核即时处理的。

结合你提供的内核代码片段补充说明：
你贴的代码是信号默认行为的处理分支，但内核在进入这个分支前，已经完成了恢复进程的关键步骤：

1. 当SIGCONT送达停止的进程时，内核首先将进程状态从停止态改为TASK_RUNNING；
2. 调用wake_up_process()把进程加入调度队列，使其具备被CPU调度的资格；
3. 之后才进入你提供的代码逻辑，此时进程已经恢复，所以默认行为分支里的continue只是跳过后续默认处理，不影响进程恢复的结果。

简言之，在kill -CONT执行的那一刻，内核就完成了进程状态切换和调度队列加入的操作，进程接下来只需要等待CPU调度就能恢复运行。

内容的提问来源于stack exchange，提问作者Markity