[ruby-dev:22880] Re: io/nonblock

In article <[e-mail]>,
  [e-mail] writes:

> どうなんでしょうねぇ。たしかに、他のプロセスにも影響したりして、
> 使いにくいんですが。

えぇ。他のプロセスへの影響は避けようがないので、一番大きな問題ですね。
[ruby-core:1494] で触れた、ssh と emacs の例はなかなか強烈です。
また、DJB は他のプロセスへの影響およびそれに関連する race condition を
避けようがないという理由で新しいシステムコールの導入を主張しています。
http://cr.yp.to/unix/nonblock.html

また、stdio との関係では [ruby-bugs-ja:432] の fflush()がEAGAINのとき
でもバッファのデータを捨ててしまうという問題があります。

あと、[ruby-talk:66198] で述べられている thread を使っているかどうかで
挙動が変わるという問題もあります。

結局の所、普通のコードは IO がブロッキングモードであることを仮定してい
ることが多いので、nonblock では意図通りに動くとは限りません。
[ruby-bugs-ja:432] は stdio が nonblock を考慮していないからですし、
[ruby-talk:66198] は ruby が nonblock を考慮していないからです。

したがって、おそらく本質的には [ruby-dev:17863] でいうところの「モード
はやめましょう」というのが重要で、モードを切替える操作を容易にするより
は、nonblock を使わなければいけなかった状況を解決する機能を導入するの
が適切でしょう。そして、必要ならその機能の内部で一時的に nonblock を使
うのは有りでしょうが。

ついでにいえば、いまさらではありますが、nonblock 時の IO#read の挙動の
決定に影響した感のある [ruby-dev:17862] は今は後悔していて、その問題は
sysread で解決したほうが適切だった、と思っています。

そして、[ruby-talk:87946] を読む限りでは今回のきっかけとなった人が欲し
いのは
  buf = fd.read_all_available_bytes_but_do_not_block
だそうですから、[ruby-dev:17862] に書いた私の要求の「到着しているぶん
を全部読みたかった」と非常に良く似ています。これらは sysread (と
select) が使えれば nonblock は使わずに実装できます。唯一の問題は
sysread は stdio を使うメソッドと混用できないため、sysread を使ったと
たんに IO の他のメソッドが使えなくなることです。だから、stdio と協調す
る sysread が欲しいわけです。

>> 個人的には、欲しいのは stdio に協調して動く sysread です。stdio のバッ
>> ファにデータが溜ってる時には、sysread がそっちから読んでくれると嬉しい
>> ですね。sysread は即座に得られるデータがない時以外はブロックしないので、
>> データがどうしても必要になってから sysread を呼べば、nonblock はだいた
>> い必要ないと思います。
>
> sysreadもブロックするはずですが。

即座に得られるデータが 1byte でもあれば partial read になるのでブロッ
クしないと理解しています。

即座に得られるデータがない時以外にブロックすることってあるんですか?
-- 
[田中 哲][たなか あきら][Tanaka Akira]