From: Yukihiro Matsumoto <matz@...>
Date: 2005-02-24T14:49:06+09:00
Subject: [ruby-dev:25759] Re: I/O operation differs signal handler

まつもと ゆきひろです

In message "Re: [ruby-dev:25758] Re: I/O operation differs signal handler"
    on Thu, 24 Feb 2005 14:12:09 +0900, Tanaka Akira <akr@m17n.org> writes:

|> その指摘の意味は「そのあとの展開でこのリビジョン(1.55)の変更
|> は不要になっているはず」が真実でないという意味でしょうか。そ
|> れとも、また別の意味？
|
|[ruby-dev:25003] の callcc への対処としては不要になっていますが、他の
|問題を防ぐのに有用にもなり得るという意味です。

なるほど。

|TRAP_BEG, read/write, TRAP_END の順で実行している最中に signal が到着
|した場合、タイミングとしては以下の 4通りが考えられます。
|
|(1) read/write が起動する前
|(2) read/write の起動中、まだデータが転送されていないとき
|(3) read/write の起動中、1byte 以上データが転送されたとき
|(4) read/write が終了した後
|
|ここで、(3), (4) の状況で signal が届いた場合、データの転送が既に行わ
|れているため、IO バッファの状態を更新すべきです。しかし、signal
|handler から ruby コードを直接実行すると、その更新が行われないままに動
|作するので、read で読んだものが読まれていないとか、write で書いたもの
|が書かれていないなど、一貫性が成り立っていない状態で動作することになり
|ます。そのコードが IO オペレーションを行わなければいいのですが、行うと
|変なことが起こります。

IOルーチンの再入を禁止するので良いのではないですか。つまり、
fptrにフラグを用意して読み込み中は読み込みフラグを立てるとい
うことですが。例外をあげるとよくないのかな。

ところで、青木さんの問題はread(2)がEINTRで中断されないのが原
因のように思えるのですが、なんでシグナルハンドラが呼び出され
てもEINTRにならなくなったんですかね。

                                まつもと ゆきひろ /:|)