- PR -

Perl の標準エラー出力を Process.getErrorStream() で読むとブロックしてしまう

«前のページへ 1|2
投稿者投稿内容
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2003-09-09 23:28
unibon です。こんにちわ。

引用:

Ken-Labさんの書き込み (2003-09-09 16:15) より:
では、なぜENDリテラルの有無を問題にしたかと言いますと、サンプルを手で
perl -c -w
for ($i=0; $i < 10;$i++){
print $i;
}
と打った場合このままになり、__END__を打ってから -Syntax OK が戻り停止します。
このサンプルを誤って入力した場合は } を入力した直後
Syntax error at - line 1, near "0;"
Syntax error at - line 1, near "++)"
- had compilation errors.
となり即停止します。普通ストリームをcloseした段階でperlが実行されるはずですが、
それが終端であると判断されなかった場合、perlから応答が得られず
BufferedReader#readLineが入力待ちになるのでは？？という推測をたてたためです。

ありがとうございます。今回の私のケースは、これが原因でした。
すなわち、writer.close(); の直前に、
コード:
        writer.write(0x1a); // Ctrl-Z

か、もしくは、

コード:
        writer.write("__END__");
        writer.newLine();

のいずれかをすると解決できました。なお、0x4(Ctrl-D)は効きませんでした。
EPIC のプラグインも、ソースコードでこれに相当する部分を修正すると、動作しました。
ちなみに Windows XP だと、これらの対処をしなくても動きました。
Windows 98 と Windows XP でなぜ違うのかは不明のままですが。

なお、引用の順序が逆になりましたが、

引用:

Ken-Labさんの書き込み (2003-09-09 16:15) より:
> 子プロセスのSTDOUT,STDERRをそれぞれ別のスレッドから吸い出してやるしかないようです。

確かにこれが図星のような気がします。

のように別スレッドにすることも、
大量の入出力があるような場合には必要のようでした。
Perl の標準入力、標準出力、および、標準エラー出力ごとに、
別々のスレッドを用意して動かさないと、ふんづまりになることがあるようでした。
＃あまり良くためしていませんので、これはちょっとあいまいです。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）