パイプ処理における遅延評価の問題（SIGPIPE問題） - Qiita
パイプ処理における問題といえば、例のcat file | while readの同一変数が別コンテキストになる問題でしょ？と思われたかもしれないですが、それとはまた別のお話でして。 上記のコードを実行すると、画面上には1～10が表示されます。 パイプ前段のプロセスが無限に標準出力する場合でも、パイプ後段のプロセスが必要な結果だけ取得できれば事足りるので、前段プロセスが愚直に最後まで計算を続けたりする必要はない。これはかしこい。 ただ、このようなイケてる遅延評価があだとなり、結果的に、ユーザの思惑に反する挙動をしてしまうケースもあります。 例えば以下のコードの場合、書かれてある通りに解釈すれば、本来ファイルにはi=99まで出力されてしかるべきなんですが、実行してみるとi=15までしか出力されませんでした。 i=16を書き込もうとしたタイミングで、書き込もうとしたパイプが後段プロセスによってク
世にも恐ろしいSIGPIPE、ソケットプログラミングの落とし穴 - 百日半狂乱
前回、「次回もシグナルのことを書く」と書いたのでシグナルのことを書く*1. ソケットプログラミングの落とし穴は色々あるけど、ここでは個人的に嵌ったシグナル関連の落とし穴に関して書き殴る． 結論から書くと、コネクションが切れたソケットに書き込み(send(2)とかwrite(2)とか、同じものだけど)を行うと、SIGPIPEシグナルが発生してプロセスが強制終了するので、きちんとSIGPIPEシグナルをハンドリングしておこうという話． 以下では、サンプルコードを使って、実際にパイプの書き込み先をkillして、SIGPIPEの発生を疑似体験してみる． SISGPIPEを受けたプロセスの挙動とソケットプログラミングでの対応策 「sigpipe」で検索すると、同様の話はいくらでも記事になっていて、例えば、 「私の書いたサーバが突然死するんです。どうしてでしょうか」という質問を受けることがあります。こ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
