Python signal.signal 是否阻止传播？

Question

所以我有这段代码(部分取自 python 文档):

import signal

def handler(signum, frame):
    print 'Signal handler called with signal', signum

s = signal.signal(signal.SIGINT, handler)

some_fancy_code() # this code is using subprocess.Popen() to call another script

singal.signal(signal.SIGINT, s)

我现在发现，如果我在我的程序中执行 Ctrl+C，它会正确地进入该处理程序并打印。现在，我的想法是，在收到 Ctrl+C 后，我的处理程序将抑制默认处理程序，例如我的 subprocess.Popen 将不会收到 KeyboardInterrupt 信号。但事实并非如此。

但是当我们用“signal.SIG_IGN”替换“handler”时，这种传播永远不会发生。修改后的片段:

import signal

s = signal.signal(signal.SIGINT, signal.SIG_IGN)

some_fancy_code() # this code is using subprocess.Popen() to call another script

singal.signal(signal.SIGINT, s)

这是因为 SIG_IGN 是某种用语言本身编写的“魔法”信号吗？或者也许有一种方法可以在我自己的处理程序中进行类似的抑制？

在阅读了一些关于堆栈溢出的问题后，我有点困惑。如果有人能为我弄清楚为什么会出现这种行为差异。

Answer 1

这是信号的指定 POSIX 行为:

   A child created via fork(2) inherits a copy of its parent's signal dis‐
   positions.  During an execve(2), the dispositions  of  handled  signals
   are  reset to the default; the dispositions of ignored signals are left
   unchanged.

当你在第一种情况下执行(fork/execve)你的另一个脚本时，SIGINT 处理程序被重置为另一个脚本中的默认处理程序(默认行为是终止进程) - 当然，另一个脚本可以安装它自己的处理程序并更改此行为。

但是，在第二种情况下，您已将 SIGINT 配置为忽略。如上面的定义所示，此行为将传播到另一个脚本。同样，另一个脚本可以通过安装自己的处理程序来更改此行为。

所以这与 Python 没有直接关系。这是底层操作系统的 POSIX 信号处理实现的预期行为。

PS. 如果您想知道 fork() 和 execve() 是什么，fork() 会创建正在运行的进程(一个子进程)的副本，而 execve() 会将当前进程替换为其他。这是 subprocess.Popen() 用来运行“另一个脚本”的底层机制:首先复制当前进程，然后用目标进程替换它。