From: nobu@...
Date: 2005-06-02T08:21:29+09:00
Subject: [ruby-dev:26263] Re: IO.select dumps core

なかだです。

At Thu, 2 Jun 2005 04:18:40 +0900,
Tanaka Akira wrote in [ruby-dev:26262]:
> 基本的な方針は「なぜか余計にメモリを確保しておいて動いたらラッキー」な
> ので、今まで参照していなかった FD_SETSIZE は今さら参照しなくても書ける
> はずなんじゃないかと思います。

あまりFD_SETSIZEを避ける必要もないとは思いますが。

> FD_ZERO による初期状態が 0 の並びでない可能性を考慮するなら、FD_ZERO
> は常に行うべきでしょう。
> 
>     if (fds->fdset) {
> 	MEMZERO(fds->fdset, fd_mask, howmany(fds->maxfd, NFDBITS));
> 	FD_ZERO(fds->fdset);
>     }

そうかも。

> >> # Windows の fd_set は違うというので探したら、
> >> # http://msdn.microsoft.com/library/en-us/winsock/winsock/fd_set_2.asp
> >> # を見る限りは MEMZERO だけでよさそうですねぇ。
> >
> > そもそもwinsockがFD_SETSIZE以上を見てくれるかどうか、というより
> > もWaitForMultipleObjects()が見てくれなさげ。
> 
> MEMZERO だけでいいというのは、FD_ZERO と同等の効果がありそうだ、という
> 意味です。

いや、そもそもWindowsではFD_SETSIZE以上を渡しても意味はないし、
FD_SET()でも単純に無視しているので、この変更の対象外という意味
です。というかそのためにNFDBITSで分けてます。

どちらかといえば、[ruby-core:05088]のようにselect()がソケットし
か扱えない環境では、ソケット以外を別扱いにするコードを含めたほ
うがいいのかも知れません。

> FD_SETSIZE以上のサポートを広げるという意味では、poll にする意味が有る
> かというのが興味の有るところなのですが、Windows は救えなさそうですね。
> (そもそも Windows に poll があるのかどうか知りませんが)

システム自体が64までしかサポートしないので、native threadを立ち
上げてカスケードするしかなさそうです。

> poll にすれば救える環境って存在するのかなぁ?

SysVベース?

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦