我有一个模拟程序，它通过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 下，程序运行并通过stdin获取命令（这已通过调试子进程验证），但是python程序死锁在任何p.stdout.readline和p.wait。如果删除stdout=subprocess.PIPE参数，程序可以正常运行，则输出显示在控制台上，不会发生死锁。
这听起来很熟悉Python文档中的警告：
警告：当使用stdout = PIPE和/或stderr = PIPE并且子进程为管道生成足够的输出时，这将会死锁 这样它就会阻止等待OS管道缓冲区接受更多 数据。使用communic（）来避免这种情况。
但是，我不能使用communication（），因为程序协议不是单个命令和单个输出，而是需要几个命令和回复。
有没有解决方案？
答案 0 :(得分：1)
不确定，但它看起来像缓冲问题。在Linux上（与大多数Unix或类Unix一样），在OS级别内部缓冲输出到文件或管道。这意味着在write调用之后，所有数据都被缓冲，但管道的另一端没有任何数据可用，直到内部缓冲区已满，数据被刷新或管道关闭。这就是为什么pty被发明并且不用管道对实现的原因之一。
换句话说，不可能驱动一个程序，你需要使用以前的输出知道你应该用管道输入什么，除非程序是通过在读取任何内容之前一直刷新其输出而专门为它定制的。它适用于真正的终端（tty或pty），因为在同一设备上读取之前，驱动程序会自动强制刷新输出。
但它与您在问题中引用的文档中描述的处理方式不同。