ささだです。

　いつもわかりやすく説明していただいてありがとうございます。

Shiro Kawai wrote:
> ここのコードは、「システムコールをブロックさせない」という
> 意図ではありません。システムコール中にシグナルが届いちゃった
> 場合を処理しているだけのコードです。

　なるほど。

> アプリケーション側のスタンスとしては、ブロックする可能性のある
> スレッドに重要なシグナルの処理をやらせるのがそもそも間違いである、
> という考えです。確実にシグナルを受け取りたいなら、シグナルを
> 受けるスレッドをひとつ決めてsys-pauseで待つようにします
> (sys-pauseの実装は内部でsigsuspendを使っていて、このハザードを
> 避けています)。
> 
> なお、ここで問題にしているのはプロセスワイドの非同期シグナル
> だけです。pthread_killによるスレッド間のシグナル配送は
> 色々なハザードが多すぎて、一般的に使うべきメカニズムでは
> ありません。(そもそも、pthread_cond_waitで待っている時に
> シグナルを受けた場合、シグナルハンドル後に
> pthread_cond_waitが中断されるか再び待ちに入るかは
> 実装依存なんです。だから他のシステムコールでいくら工夫
> しても無駄です)。

　なるほど。pthread_cond_wait() はそんな罠が。

　Boehm GC は同期を取るために pthread_kill() を使っていますが、... っ
て、Boehm GC の同期は signal handler 内で処理するから、シグナルによって
割り込まれた元は関係ないんですね。


　たとえば、read でブロックするようなスレッドがあった場合、一回の SIGINT
でこれを解除することを保障するというプログラムは安全・ポータブルには書け
ないってことなんでしょうか。

- Thread A が read 専用のスレッド (Thread B) をつくり、
- Thread A は sigsuspend() で待ち、
-- SIGINT で Thread A が起きたら、Thread B に対して pthread_cancel()
- Thread B で read が完了したら、pthread_kill() で Thread A を起こす

なら出来る？（重い read だな...）　あ、read の結果を捨てる、という
longjmp と同様の問題があるのか orz

-- 
// SASADA Koichi at atdot dot net

-- 
ML: yarv-dev quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml