[ruby-dev:26644] Re: [ruby-cvs] ruby/ext/socket, ruby, ruby: * ext/socket/socket.c (ruby_connect): break immediately if a

まつもと ゆきひろです

In message "Re: [ruby-dev:26633] Re: [ruby-cvs] ruby/ext/socket, ruby, ruby: * ext/socket/socket.c (ruby_connect): break immediately if a"
    on Thu, 28 Jul 2005 21:46:59 +0900, Tanaka Akira <[e-mail]> writes:

|> ふーむ、ここで初めて気がついたのですが(遅い)、デフォルトで
|> nonblockingにするということは、IOをnonblockingに設定しても各
|> メソッドはブロックする(かもしれない)ことを意味するんですね。
|> すでにあちこちそうなっていて文句も出てないということは気にし
|> なくても良いということなのかもしれませんが。
|
|むしろ積極的に blocking mode と同じように動作するのが良いと私は思って
|います。
|
|IO#write でブロックしても他のスレッドが動くように nonblocking にしたら
|IO#read が変わって困る、という最近の例がわかりやすいと思いますが、
|IO#read を呼ぶコードを書くときにはそれが nonblocking で挙動が変わると
|いう意識は無いわけです。
|
|挙動が変わるという意識がないのに挙動が変わればそれは問題になりますから、
|他のスレッドが動けるかどうか以外の影響は無いほうがいいでしょう。

Rubyのスレッドについてそれほど知識がなくUNIX的伝統だけを知っ
ている人の場合、IOオペレーションでブロックしないために
nonblockingにするのではないでしょうか。connectの例はまさにそ
れですね。つまり、noblockingにする人の中には明らかに「挙動が
変わる」ことを期待する人もいるわけです。また、nonblockingと
いう名前を持つフラグを設定していながら、実際にはメソッドはブ
ロックするというのも矛盾した状態ではあります。UNIXでの
nonblockingフラグがシステムコールがブロックしないことを目的
としたフラグである以上、「挙動が変わらない」ということは、
Rubyにおけるnonblockingの意味を変えているということになりま
すね。

変えることがいけないわけではありませんが、変わっていることを
自覚する必要はあるでしょう。で、すべてを同時に満足することは
できないので、どの辺を選ぶかですよね。

|では nbconnect とか。

connect_nonblockの方がマシですね。^^;;;

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