问题是，如Python信号处理程序的执行中所述：
Python信号处理程序不会在底层（C）信号处理程序中执行。相反，低级信号处理程序设置一个标志，该标志告诉虚拟机在以后的点（例如，在下一个字节码指令处）执行相应的Python信号处理程序。
…
纯粹以C语言实现的长时间运行的计算（例如，大文本正文上的正则表达式匹配）可能会在任意时间内连续运行，而不管收到任何信号。计算完成后，将调用Python信号处理程序。
您的主线程被阻塞在上threading.Thread.join，这最终意味着它在pthread_join调用中被C阻塞了。当然，这不是“长时间运行的计算”，而是syscall上的一个块……但是，在该调用结束之前，您的信号处理程序将无法运行。
而且，虽然在某些平台上pthread_join会EINTR因信号失败，但在其他平台上却不会。在Linux上，我相信这取决于您选择的是BSD样式还是默认siginterrupt行为，但是默认值为no。
所以你能对它做点啥？
好吧，我很确定Python 3.3中对信号处理的更改实际上改变了Linux上的默认行为，因此，如果升级，您将不需要做任何事情。只需在3.3+下运行，您的代码即可按预期运行。至少它对我来说适用于OS X上的cpython 3.4和Linux上的3.3。（如果我错了，我不确定这是否是cpython中的错误，因此您可能想在python- list上引发它，而不是打开一个问题…）
另一方面，在3.3之前的版本中，该signal模块肯定不会提供您自己解决此问题所需的工具。因此，如果您不能升级到3.3，解决方案是等待诸如aCondition或an之类的可中断内容Event。子线程在退出之前立即通知事件，而主线程在加入子线程之前等待事件。这绝对是hacky。而且我找不到任何可以保证会有所作为的东西。它恰好可以在OS X的各种cpython 2.7和3.2以及Linux的2.6和2.7的各种版本中为我工作…
602392714
清零编程群