为什么使用 threading.Event 会导致 SIGTERM 未被捕获？

Question

我有一个线程Python 守护进程。像任何好的守护进程一样，它想要启动所有工作线程，然后等待，直到被告知终止。正常的终止信号是 SIGTERM，在大多数语言中，我会通过等待事件或互斥体来终止，因此使用 threading.Event 对我来说很有意义。问题是 Python 的 Event 对象和 Unix 信号似乎不能很好地协同工作。

这按预期工作，终止于 SIGTERM：

import signal
import time

RUN = True

def handle(a, b):
    global RUN
    print "handled"
    RUN = False

signal.signal(signal.SIGTERM, handle)
while RUN:
    time.sleep(0.250)
print "Stopping"

但这会导致没有 SIGTERM 被传递（即，除了退出之外，“handled”永远不会被打印）：

import signal
import threading

RUN_EVENT = threading.Event()

def handle(a, b):
    print "handled"
    RUN_EVENT.set()

signal.signal(signal.SIGTERM, handle)
RUN_EVENT.wait()
print "Stopping"

所以我的问题是：

1. 我是否以某种方式滥用了threading.Event？
2. 如果我不是，除了第一个示例中的轮询和睡眠机制之外还有其他选择吗？
3. 另外，如果我不是，为什么使用 threading.Event 会杀死信号处理程序？

Answer 1

来自 有关信号的 Python 文档：

尽管就 Python 用户而言，Python 信号处理程序是异步调用的，但它们只能发生在 Python 解释器的“原子”指令之间。这意味着在纯粹用 C 实现的长计算期间到达的信号（例如对大量文本进行正则表达式匹配）可能会延迟任意时间。

我测试了各种 threading 和 thread 类，但它们都没有按照您想要的方式工作——这可能是因为 Python 处理信号的方式。

然而，在 signal 中，有一个 < code>pause() 函数，该函数会休眠直到进程收到信号。您修改后的示例如下所示：

import signal

RUN = True

def handle(a, b):
    global RUN
    print "handled"
    RUN = False

signal.signal(signal.SIGTERM, handle)
signal.signal(signal.SIGINT, handle)
signal.signal(signal.SIGHUP, handle)

while RUN:
    signal.pause()

print "Stopping"

我在 Linux 上检查了它，它有效。如果您的应用程序不使用大量其他信号，我认为它不再归类为轮询和睡眠。

处理 SIGINT 和 SIGHUP 也很好，可以正确处理用户中断（通常通过按 Ctrl+C）和用户断开连接（关闭父进程）终端）分别。

另请注意 signal.pause() 在 Windows 系统上不可用。

Answer 2

在 Python 3 中，这有效：

from threading import Event
from os import getpid
from signal import SIGTERM, SIGINT, SIGHUP, signal

stop_event = Event()

def handler(signum, frame):
    stop_event.set()

def main():
    signal(SIGTERM, handler)
    signal(SIGINT, handler)
    signal(SIGHUP, handler)
    print('start, pid:', getpid())
    stop_event.wait()
    print('done')

if __name__ == '__main__':
    main()

看起来在 Python 2.7 中，只有指定等待间隔时，它才有效：stop_event.wait(number_of_seconds)