2012-01-27 10 views
5

QT/C++で書かれたロングランサーバープログラム(たとえば、プログラムA)があります。プログラムはそれほど安定していないので、クラッシュした場合はPythonスクリプトを書いて再起動します。問題は、プログラムが失敗した(私が使用中のポートを与えた場合)、エラーを表示して終了せずにそこにハングアップすることがあるため、プログラムのstdoutを監視して起動に失敗する必要があるということです。パイプリダイレクトを使用するとWindowsコンソールプログラムのstdoutがバッファリングされる

これが私の最後のコードの一部(実際には、これはokですだけでなく、あなたはそれを無視することができます)です。

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='') 

しかし、私は、サブプロセスの標準出力からのreadlineを何も読み取ることができないましたメソッドはちょうどそこにブロックされ、私はAプロセスを殺すと、pythonスクリプトは出力せずに終了します。最初は、サブプロセスモジュールの問題だと思っていましたが、いくつかのテストの後、私はそれがないと判断しました。 A.exeコマンドラインを他のWindowsコンソールプログラムで置き換えると、例えば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"); 

いくつかの検索の後、私は今、コードのこの作品の最後にfflush(stdout);を追加し、プログラムを再構築して、それは動作します

私の問題は、私はまだ理解できない、何がオリジナルのプログラムコードに間違っているのですか?強制フラッシュせずに、プログラムを開始した直後に、Windowsコンソールでこれらの文字列を正しく印刷することができます。パイプを使用して出力をバッファリングする理由標準のC実装では、出力は改行で自動でフラッシュされますが、なぜ私の状況ではないのでしょうか?これはWindowsの問題、またはコンパイラの問題ですか?

AプログラムはQT/C++でコンパイルされ、QTバージョンは4.7.4(x32)、C++コンパイラはQT(GCC 4.4.0)に付属するming32 g ++、すべてのテストはwin7x64プラットフォームで行われました。私のpythonのバージョンは2.7.2です

答えて

1

私はあなたと同じ質問に出くわしました。パイプの (How fo force subprocess to refresh stdout buffer?

標準出力ウィンドウにリダイレクトが完全にdefaultlyバッファされ、それがサブプロセスの実行が終了またはサブプロセスでprintfの後にfflushを呼び出すようにしない限り、あなたはパイプから何かを読んカントを意味します。

これはWindowsの問題ではなく、設計上の問題などの問題があります。

そして、私はこの問題の良い解決策を見つけました。あなたがそれを解決すれば教えてください。

+0

あなたのリンクのコメントの[関連リンク](http://stackoverflow.com/q/20503671/4279)は、大いに感謝してくれます – adamhj

関連する問題