一个Reentrant Error引发的对Python信号机制的探索和思考

51CTO诚邀您9月23号和秒拍/国美/美团元专家一路聊智能CDN的优化之路，抓紧时光哦！

写在前面

前几天工作时碰到了一个匪夷所思的问题。经由几回测验测验后问题得以解决，但问题产生的原因却仍令人费解。查找 SO 无不雅，我决定翻看 Python 的源码。断断续续地研究了几天，终于恍然大年夜悟。撰此文以记。

本文情况：

Ubuntu 16.04 (64 bit)
Python 3.6.2

应用的 C 源码可以大年夜 Python 官网获取。

原由

工作时用到了 celery 作为异步义务队列，为便利调试，我写了一个脚本用以启动/封闭 celery 主过程。代码简化后如下：

代码启动了 celery worker，尝尝试在捕获到 KeyboardInterrupt 异常时将其热封闭。

初看上去没什愦问题。然而实际测试时却产生了十分诡异的工作：按下 Ctrl+C 后，法度榜样有时会抛出如许的异常：RuntimeError: reentrant call inside <_io.BufferedWriter name='<stdout>’>。诡异之处有两点：

这个结不雅大年夜大年夜出乎了我的料想。随机性异常是浩瀚最难缠的问题之一，因为这常平平易近味着并发问题，涉及底层常识，病灶隐蔽，调试难度大年夜，同时没有有效的手段断定问题是否彻调果断(可能只是降低了频率)。

异常信息中有两个词很关键：reentrant 和 stdout。reentrant call 解释有一个弗成重入的函数被递归调用了;stdout 则指清楚明了产生的地点和机会。初步可以剖断：因为某种原因，有两股控制流在同时操控 stdout。

“可重入”是什么?根据 Wikipedia 的定义：如不雅一个子法度榜样能在履行时被中断并在之后被精确地、安然地唤起，它就被称为可重入的。依附于全局数据的过程是弗成重入的，如 printf(依附于全局文件描述符)、malloc(依附与和堆相干的一系列数据构造)等函数。须要留意的是，可重人道(reentrant)与线程安然性(thread-safe)并不等价，甚至不存在包含关系，Wikipedia 中给出了相干的反例。

多次测验测验后，出现了一条线索：有时刻 worker: Warm shutdown (MainProcess) 这个字符串会被二次打印，机会不肯定。这句话是 celery 将要热封闭时的提示语，二次出现只可能是主过程收到了第二个旌旗灯号。浏览 celery 的文档可知，SIGINT 和 SIGTERM 旌旗灯号可以激发烧封闭。回头浏览我的代码，个中只有一处发送了 SIGTERM 旌旗灯号(celery_process.terminate())，至于另一个神秘的旌旗灯号，我困惑是 SIGINT。

SO 一下，结不雅印证了我的猜想：

If you are generating the SIGINT with Ctrl-C>

# ...

try:

# Start and wait for server process

except KeyboardInterrupt:

# Ctrl + C pressed

pass

else:

# Signal SIGTERM if no exception raised

celery_process.terminate()

finally: