Python 子進程和標准輸出 - 程序死鎖

Question

我有一個模擬程序，它通過 stdin 進行引導，並向 stdout 提供輸出

做一個C++/Qt程序在 QProcess 中運行它效果很好。

做一個在linux下運行它的Python程序效果很好，使用：

p = subprocess.Popen(cmd,stdin=subprocess.PIPE,stdout=subprocess.PIPE)

並使用p.stdin.write 、 p.stdout.readline和p.wait

然而，在windows下，程序運行並通過標准輸入獲取命令（這已通過調試子進程驗證），但 python 程序在任何p.stdout.readline和p.wait處死鎖。 如果去掉stdout=subprocess.PIPE參數，則程序運行，控制台顯示輸出，不會發生死鎖。

這聽起來很熟悉 Python 文檔中的警告：

警告：當使用 stdout=PIPE 和/或 stderr=PIPE 並且子進程生成足夠的輸出到管道時，這將死鎖，從而阻止等待 OS 管道緩沖區接受更多數據。 使用communication() 來避免這種情況。

但是，我不能使用communication()，因為程序協議不是單個命令和單個輸出，而是需要多個命令和回復。

有什么解決辦法嗎？

Answer 1

不確定，但它看起來像一個緩沖問題。 在 Linux 上（就像在大多數 Unix 或類 Unix 上一樣），文件或管道的輸出在操作系統級別進行內部緩沖。 這意味着在write調用之后，所有數據都被緩沖，但管道的另一端沒有可用的數據，直到內部緩沖區已滿、數據被刷新或管道關閉。 這就是為什么pty被發明並且沒有用管道對實現的原因之一。

換句話說，在需要使用以前的輸出來知道應該使用管道作為輸入提供什么的情況下，驅動程序是不可能的，除非該程序是專門為它量身定制的，在讀取任何內容之前始終刷新其輸出。 它適用於真正的終端（tty 或 pty），因為在同一設備上進行任何讀取之前，驅動程序會自動強制刷新輸出。

但這與您在問題中引用的文檔中描述的 delock 不同。