Windows控制台程序stdout在使用pipe道redirect时被缓冲

我有一个长期运行的服务器程序(比如程序A),它是用QT / c ++编写的。 该程序是不是很稳定,所以我决定写一个python脚本来重新启动它,如果它崩溃。 问题是程序可能开始失败(如果我给它一个使用中的端口),打印错误,然后挂在那里没有退出,所以我必须监视程序的标准输出,并在失败的启动时杀死它。

这是我的最终代码(呃,其实这是好的,你可以忽略它):

self.subp = subprocess.Popen( r'.\A.exe -server %d' % portnum, stdout=subprocess.PIPE, bufsize=1) for line in iter(self.subp.stdout.readline, ''): print(line, end='') 

但我发现我不能从subprocess的标准输出读取任何东西,readline方法只是阻止那里,如果我杀了一个进程,python脚本只是退出没有任何输出。 在一开始,我认为这是一个subprocess模块的问题,但经过一些testing,我发现它不是。 如果我用一些其他的Windows控制台程序replaceA.exe命令行,ping -t例如,一切工作正常。 所以我认为这可能是A程序的问题。

幸运的是,我有A的源代码,这里是一个输出处理:

 printf("Server is starting on port %u\n", Config.ServerPort); if(server->listen()) printf("Starting successfully\n"); else printf("Starting failed!\n"); 

经过一些search,我添加fflush(stdout); 到这段代码的末尾,重build程序,现在它工作

所以我的问题是,我还是不明白,原来的A程序代码有什么问题? 不用强制刷新,它可以在程序启动后立即在Windows控制台中正确打印这些string。 为什么在输出上使用pipe道时输出缓冲? 我在标准c实现读取,输出将自动刷新换行,但为什么不在我的情况? 这是一个Windows的问题,或编译器的问题?

A程序是用QT / C ++编译的,QT版本是4.7.4(x32),C ++编译器是用QT(GCC 4.4.0)来的ming32 g ++,所有的testing都是在win7x64平台上完成的,我的python版本是2.7.2

Solutions Collecting From Web of "Windows控制台程序stdout在使用pipe道redirect时被缓冲"

我遇到了和你一样的问题。 ( 如何强制子进程刷新stdout缓冲区? )

默认情况下,管道重定向的标准输出默认情况下,它意味着你不能从管道读取任何东西,除非子进程运行结束或在子进程中调用printf之后的fflush。

这不是Windows问题,而是通过设计,有时它像一个问题。

我曾经为这个问题找到了一个很好的解决方案,告诉我如果你解决了这个问题。