In article <1122518643.429222.1408.nullmailer / x31.priv.netlab.jp>,
  Yukihiro Matsumoto <matz / ruby-lang.org> writes:

> ふーむ、ここで初めて気がついたのですが(遅い)、デフォルトで
> nonblockingにするということは、IOをnonblockingに設定しても各
> メソッドはブロックする(かもしれない)ことを意味するんですね。
> すでにあちこちそうなっていて文句も出てないということは気にし
> なくても良いということなのかもしれませんが。

むしろ積極的に blocking mode と同じように動作するのが良いと私は思って
います。

IO#write でブロックしても他のスレッドが動くように nonblocking にしたら
IO#read が変わって困る、という最近の例がわかりやすいと思いますが、
IO#read を呼ぶコードを書くときにはそれが nonblocking で挙動が変わると
いう意識は無いわけです。

挙動が変わるという意識がないのに挙動が変わればそれは問題になりますから、
他のスレッドが動けるかどうか以外の影響は無いほうがいいでしょう。

IO オブジェクト (に対応する file description) につけるフラグで挙動を変
えると予期しないところに影響が出て間違いの元ですから、そのような変化は
可能な限り減らしたほうがいいと思います。

> 気に入りません。最悪というほどではないですが。
> なにか良い名前がありませんかねえ。

まぁ、どうせ気に入らないだろうとは思っていましたが。

では nbconnect とか。

> あらゆるIOオペレーションをブロックせずに行いたいというニーズ
> が本当にあるのであれば、OpenFile構造体のフラグとして追加する
> (FMODE_BINMODEのように)という手もありますが、そこまでする必
> 要もないような気もします。

そのニーズはどうなんでしょうねぇ。ML を眺めていても、いまのところそう
いう具体的なニーズを見た覚えはありません。また、私は nonblocking にし
たいという意図をフラグで表現するのは間違いの元だと考えています。

しかし、OpenFile構造体のフラグによってプログラマの意図を表現することは
たしかに可能ではあります。要するにそれは [ruby-dev:26492] の前田さんの
案の延長なわけですが。

しかし、これはやりすぎな感じがしますし、IO オブジェクトと OS で似て非
なるフラグがあるのは混乱の元だと思います。

が、それでも、フラグにアクセスするメソッドの名前のほうが簡単に思い付け
るのであれば、そっちのほうが面倒が無いかもしれませんね。名前を説得する
のは骨が折れるので。
-- 
[田中 哲][たなか あきら][Tanaka Akira]