一個 Reentrant Error 引發的對 Python 信號機制的探索和思考
(點擊
上方藍字
,快速關注我們)
來源:hsfzxjy
https://segmentfault.com/a/1190000010722497
如有好文章投稿,請點擊 → 這裡了解詳情
寫在前面
前幾天工作時遇到了一個匪夷所思的問題。經過幾次嘗試後問題得以解決,但問題產生的原因卻仍令人費解。查找 SO 無果,我決定翻看 Python 的源碼。斷斷續續地研究了幾天,終於恍然大悟。撰此文以記。
本文環境:
Ubuntu 16.04 (64 bit)
Python 3.6.2
使用的 C 源碼可以從 Python 官網 獲取。
起因
工作時用到了 celery 作為非同步任務隊列,為方便調試,我寫了一個腳本用以啟動/關閉 celery 主進程。代碼簡化後如下:
import
sys
import
subprocess
# ...
celery_process
=
subprocess
.
Popen
(
[
"celery"
,
"-A"
,
"XXX"
,
"worker"
],
stdout
=
subprocess
.
PIPE
,
stderr
=
sys
.
stderr
)
try
:
# Start and wait for server process
except
KeyboardInterrupt
:
# Ctrl + C pressed
celery_process
.
terminate
()
celery_process
.
wait
()
代碼啟動了 celery worker,並嘗試在捕獲到 KeyboardInterrupt 異常時將其熱關閉。
初看上去沒什麼問題。然而實際測試時卻發生了十分詭異的事情:按下 Ctrl+C 後,程序 偶爾 會拋出這樣的異常:RuntimeError: reentrant call inside <_io.BufferedWriter name="<stdout>』>。詭異之處有兩點:
異常發生的時機有隨機性
異常的 traceback 指向 celery 包,也就是說這是在 celery 主進程內部發生的異常
這個結果大大出乎了我的意料。隨機性異常是眾多最難纏的問題之一,因為這常常意味著並發問題,涉及底層知識,病灶隱蔽,調試難度大,同時沒有有效的手段判斷問題是否徹底解決(可能只是降低了頻率)。
解決
異常信息中有兩個詞很關鍵: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 on a Unix system, then the signal is being sent to the entire process group.
— via StackOverflow
SIGINT 信號不僅會發送到父進程,而是會發到整個進程組,默認情況下包括了所有子進程。也就是說——在攔截了 KeyboardInterrupt 之後執行的 celery_process.terminate() 是多此一舉,因為 SIGINT 信號也會被發送至 celery 主進程,同樣會引起熱關閉。代碼稍作修改即可正常運行:
# ...
try
:
# Start and wait for server process
except
KeyboardInterrupt
:
# Ctrl + C pressed
pass
else
:
# Signal SIGTERM if no exception raised
celery_process
.
terminate
()
finally
:
# Wait for it to avoid it becoming orphan
celery_process
.
wait
()
猜測
UNIX 信號處理是一個相當奇葩的過程——當進程收到一個信號時,內核會選擇一條線程(以一定的規則),中斷其當前控制流,將控制流強行轉給信號處理函數,待其執行完畢後再將控制流交還給原線程。時序圖如下:
由於控制流轉換髮生在同一條線程上,許多線程間同步機制會失效甚至報錯。因此信號處理函數的編寫要比線程函數更加嚴格,對同一個文件輸出是被禁止並且無解的,因為很可能會發生這樣的事情:
而且這個問題不能通過加鎖來解決(因為是在同一個線程中,會死鎖)。
因此,我猜測異常發生時的事件時序是這樣的:在 print 未執行完時中斷,又在信號處理函數中調用 print,觸發了重入檢測,引起 RuntimeError:
疑雲又起
不幸的是,我的猜想很快被推翻了。
在翻看 Python signal 模塊的官方文檔,我看到了如下敘述:
A Python signal handler does not get executed inside the low-level (C) signal handler. Instead, the low-level signal handler sets a flag which tells the virtual machine to execute the corresponding Python signal handler at a later point(for example at the next bytecode instruction).
— via Python Documentation
也就是說,Python 中使用 signal.signal 註冊的信號處理函數並不會在收到信號時立即執行,而只是簡單做一個標記,將其延遲至之後的某個時機。這麼做可以盡量快地結束異常控制流,減少其對被阻斷進程的影響。
這番表述可以說是推翻了我的猜想,因為 Signal Handler 中的 print 並沒有在異常控制流中執行。那異常又是怎麼產生的呢?
文檔說 Python Signal Handler 會被延後至某個時機進行,但並沒有明示是什麼時候。對於這個疑問,這個提問的被採納回答 則斬釘截鐵地將其具體化到了「某兩個 Python 位元組碼之間」。
我們知道,Python 程序在執行前會被編譯成 Python 內定的位元組碼
(bytecode),Python 虛擬機實際執行的正是這些位元組碼。倘若該回答是正確的,則立即有如下推論:在處理信號的過程中,位元組碼具有原子性(atomic)。也就是說,主線程總是在兩個位元組碼之間決定是否轉移控制流, 而 不會 出現以下情況:
這很顯然與我的程序結果相悖:print 與 print 所調用的 io.BufferedWriter.write 和 io.BufferedWriter.flush 都是用純 C 代碼編寫的,對其的調用只消耗一條位元組碼(CALL_FUNCTION 或 CALL_FUNCTION_KW),在信號中斷的影響下,這幾個函數仍保持原子性,在時序圖上互不重疊,更不會發生重入。
因此,除了在兩個位元組碼之間,應該還有其他時機喚起了 Python Signal Handler。
至此,問題已觸及 Python 的地板了,需向更底層挖掘才能找到答案。
深入源碼
信號註冊邏輯位於 Modules/signalmodule.c 文件中。 313 行的 signal_handler 是信號處理函數的最外層包裝,由系統調用 signal 或 sigaction 註冊至內核,並在信號發生時被內核回調,是異常控制流的入口。signal_handler 主要調用了 239 行處的 trip_signal 函數,其中有這樣一段代碼:
Handlers
[
sig_num
].
tripped
=
1
;
if
(
!
is_tripped
)
{
is_tripped
=
1
;
Py_AddPendingCall
(
checksignals_witharg
,
NULL
);
}
這段代碼便是文檔中所說的邏輯:做標記並延後 Python Signal Handler。其中 checksignals_witharg 即為被延後調用的函數,位於 192 行,核心代碼只有一句:
static int
checksignals_witharg
(
void
*
unused
)
{
return
PyErr_CheckSignals
();
}
PyErr_CheckSignals 位於 1511 行:
int
PyErr_CheckSignals
(
void
)
{
int
i
;
PyObject
*
f
;
if
(
!
is_tripped
)
return
0
;
#ifdef WITH_THREAD
if
(
PyThread_get_thread_ident
()
!=
main_thread
)
return
0
;
#endif
is_tripped
=
0
;
if
(
!
(
f
=
(
PyObject
*
)
PyEval_GetFrame
()))
f
=
Py_None
;
for
(
i
=
1
;
i
<
NSIG
;
i
++
)
{
if
(
Handlers
[
i
].
tripped
)
{
PyObject
*
result
=
NULL
;
PyObject
*
arglist
=
Py_BuildValue
(
"(iO)"
,
i
,
f
);
Handlers
[
i
].
tripped
=
0
;
if
(
arglist
)
{
result
=
PyEval_CallObject
(
Handlers
[
i
].
func
,
arglist
);
Py_DECREF
(
arglist
);
}
if
(
!
result
)
return
-
1
;
Py_DECREF
(
result
);
}
}
return
0
;
}
可見,這個函數便是非同步回調的最裡層,包含了執行 Python Signal Handler 的邏輯。
至此我們可以發現,整個 Python 中有兩個辦法可以喚起 Python Signal Handler,一個是調用 checksignals_witharg,另一個是調用 PyErr_CheckSignals。前者只是後者的簡單封包。
checksignals_witharg 在 Python 源碼中只出現了一次(不包括定義,下同),沒有被直接調用的跡象。但需要注意的是,checksignals_witharg 曾被當做 Py_AddPendingCall 的參數,Py_AddPendingCall 所做的工作時將其加入到一個全局隊列中。與之對應的出隊操作是 Py_MakePendingCalls,位於 Python/ceval.c 的 464 行。此函數會間接調用 checksignals_witharg,在 Python 源碼中被調用了 3 次:
Modules/_threadmodule.c 52 行的 acquire_timed
Modules/main.c 310 行的 run_file
Python/ceval.c 722 行的 _PyEval_EvalFrameDefault
值得注意的是,_PyEval_EvalFrameDefault 是一個長達 2600 多行的狀態機,是解析位元組碼的核心邏輯所在。此處調用出現於狀態機主循環開始處——這印證了上面回答中的部分說法,即 Python 會在兩個位元組碼中間喚起 Python Signal Hanlder。
而 PyErr_CheckSignals 在 Python 源碼中出現了 80 多處,遍布 Python 的各個模塊中——這說明該回答的另一半說法是錯誤的:除了在兩個位元組碼之間,Python 還可能在其他角落喚起 Python Signal Handler。其中有兩處值得注意,它們都位於 Modules/_io/bufferedio.c 中:
1884 行的 _bufferedwriter_flush_unlocked
1939 行的 _io_BufferedWriter_write_impl
這兩個函數是 io.BufferedWriter 類的底層實現,會被 print 間接調用。仔細觀察可以發現,它們都有著相似的結構:
ENTER_BUFFERED
(
self
)
//
...
PyErr_CheckSignals
();
//
...
LEAVE_BUFFERED
(
self
)
ENTER_BUFFERED 是一個宏,會嘗試申請無阻塞線程鎖以保證函數不會被重入:
#define ENTER_BUFFERED(self)
(
(
PyThread_acquire_lock
(
self
->
lock
,
0
)
?
1
:
_enter_buffered_busy
(
self
))
&&
(
self
->
owner
=
PyThread_get_thread_ident
(),
1
)
)
至此,真相已經大白了。
真相
當信號中斷髮生在 _bufferedwriter_flush_unlocked 或 _io_BufferedWriter_write_impl 中時,這兩個函數中的 PyErr_CheckSignals 會直接喚起 Python Signal Handler,而此時由 ENTER_BUFFERED 上的鎖尚未解開,若 Python Signal Handler 中又有 print 函數調用,則會導致再次 ENTER_BUFFERED 上鎖失敗,從而拋出異常。時序圖如下:
思考
為什麼不將 Python Signal Handler 調用的地點統一在一個地方,而是散布在程序的各處呢?閱讀相關代碼,我認為有兩點原因:
信號中斷會使某些系統調用行為異常,從而使系統調用的調用者不知如何處理,此時需要調用 Signal Handler 進行可能的狀態恢復。一個例子是 write 系統調用,信號中斷會導致數據部分寫回,與此相關的一大批 I/O 函數(包括出問題的 _bufferedwriter_flush_unlocked 和 _io_BufferedWriter_write_impl)便只能相應地調用 PyErr_CheckSignals。
某些函數需要做計算密集型任務,為了防止 Python Signal Handler 的調用被過長地延後(其實主要是為了及時響應鍵盤中斷,防止程序無法從前台結束),必須適時地檢查並調用 Python Signal Handler。一個例子是 Objects/longobject.c 中的諸函數,longobject.c 定義了 Python 特有的無限長整型,其相關的運算可能耗時相當長,必須做這樣的處理。
總結
Python Signal Handler 的調用會被延後,但時機不止在兩個位元組碼之間,而是可能出現在任何地方。
由於第一條,Python Signal Handler 中盡量都使用 可重入的 的函數,以避免奇怪的問題。可重入性可以從文檔獲知,也可以結合定義由源碼推斷出來。
有疑問,翻源碼。人會說謊,代碼不會。
看完本文有收穫?請轉
發分享給更多人
關注「P
ython開發者」,提升Python技能
※為提高用戶體驗,Yelp 是如何無損壓縮圖片的
※BAT 面試官帶你刷真題、過筆試
※K-means 在 Python 中的實現
TAG:Python開發者 |