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

まつもと ゆきひろです

In message "Re: [ruby-dev:26656] Re: [ruby-cvs] ruby/ext/socket, ruby, ruby: * ext/socket/socket.c (ruby_connect): break immediately if a"
    on Sun, 31 Jul 2005 02:47:13 +0900, Tanaka Akira <[e-mail]> writes:

|そして、スレッドとイベントドリブンフレームワークを比べると、スレッドは
|組み込みであることもあってスレッドのほうが多く使われていると思います。
|また、Ruby スクリプトでイベントドリブンフレームワークを記述するのはま
|さに屋上屋を架すような話な上にプログラムの構造からして変えなければなら
|なくてそれなりの覚悟がないとできないので、スレッドなプログラムを支援す
|るほうが幸せになれる人が多いと思います。したがって、基本的には既存のメ
|ソッドはなるべく blocking な振る舞いに変えていくほうが幸せなケースを増
|やせます。そして、それとは逆に、スレッドなプログラムにとって適切な振る
|舞いだった Socket#connect をあのように変えることは相対的に不幸なケース
|を増やすことになるので反対です。

なるほど。了解しました。とりあえずあの変更は取り消すことにし
ます。nonblockingなメソッドについてはひきつづき考えることに
します。

|なお、蛇足ですが、Ruby の read でも nonblocking なときにはイベントルー
|プに戻る前にまず read するようにすれば、マルチスレッドでも
|Linux 2.6 の /proc/loadavg を (nonblocking にすれば) 読めるようになっ
|ていいんじゃないかと思います。

これは毎回rb_thread_wait_fd()の中でfcntl(fd, F_GETFL, 0)して
チェックするということですかね。コストが問題でなければ
nonblockingであればすぐ返るだけなのですが。

|あとは、生の connect という意味で sysconnect でしょうか。
|
|ただ、sysconnect という名前は IO が blocking なときには blocking な挙
|動が期待される名前なので、いつでも nonblocking な挙動のメソッドにより
|イベントドリブンなプログラムを幸せにしようという狙いからは少し外れるの
|ですが。あと、Windows で nonblocking な挙動にならないか、プロセス全体
|が止まるというどちらかの問題がおきそうな気もします。

sysconnectは悪くないかなと思ったのですが、おっしゃる通り問題
がないとはいかないようですね。

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