世にも恐ろしいSIGPIPE、ソケットプログラミングの落とし穴 - 百日半狂乱
前回、「次回もシグナルのことを書く」と書いたのでシグナルのことを書く*1. ソケットプログラミングの落とし穴は色々あるけど、ここでは個人的に嵌ったシグナル関連の落とし穴に関して書き殴る． 結論から書くと、コネクションが切れたソケットに書き込み(send(2)とかwrite(2)とか、同じものだけど)を行うと、SIGPIPEシグナルが発生してプロセスが強制終了するので、きちんとSIGPIPEシグナルをハンドリングしておこうという話． 以下では、サンプルコードを使って、実際にパイプの書き込み先をkillして、SIGPIPEの発生を疑似体験してみる． SISGPIPEを受けたプロセスの挙動とソケットプログラミングでの対応策 「sigpipe」で検索すると、同様の話はいくらでも記事になっていて、例えば、 「私の書いたサーバが突然死するんです。どうしてでしょうか」という質問を受けることがあります。こ
Ctrl+Cとkill -SIGINTの違いからLinuxプロセスグループを理解する | ギークを目指して
しばらくLinuxネタが続く・・。 近いうちに最近出たJava8ネタを書いてみようと思います。が、もう少しLinuxネタにお付き合いください。 前回はsshdを対象に親プロセスをkillした場合の動作を確認した。 killされたプロセスの子プロセスは孤児プロセスとなり、カーネルによって自動的にinitプロセスの子として扱われる事を説明した。（この動作を「リペアレンティング」と呼ぶ） 今回はこの続き。 Linuxで作業していてCtrl+Cしてプロセスを終了した場合、フォアグラウンドのプロセスやその子プロセスも一緒に終了する。 ということは、子プロセスは孤児として扱われず、リペアレンティングされていないことになる。 今回の記事ではこの振る舞いの違い（リペアレンティングされるか否か）に着目し、kill -SIGINTコマンドとCtrl+Cの違いについて考えていく。 そもそもkillコマンドやCt
signal-piping - SIGNALをpipe経由でハンドラからメインスレッドに渡す方法 - spikelet days
目的 Linux上(UNIX全般)で「安全な」シグナル処理を実装したい。 本来シグナルハンドラでしてもよい処理は非常に限られており、実質は特定の型のグローバル変数操作と、非同期シグナルセーフ関数の呼び出ししか安全ではない（参考:UNIX上でのC++ソフトウェア設計の定石 (2) - memologue）。 この条件を守ったうえで、多用な処理をするシグナルハンドラを実装したい。 結果 別途、pipeとスレッド（メインスレッドでも良い）を用意して、 シグナルハンドラ: 受け取ったシグナル情報をpipeにwriteするだけ 別スレッド: pipeをreadしてその後の処理を実行 という役割分担にすれば良い。 以下、詳細。 「非同期シグナルセーフ」な関数 System Interfaces Chapter 2にあるように、非同期シグナルセーフな関数は、確かに少ない。 シグナルハンドラ内では使わなそ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
