In article <20050623125927.33401bc8.tommy / tmtm.org>,
  とみたまさひろ <tommy / tmtm.org> writes:

> ええと、「カーネルレベルでは制限がない」という話でしょうか。
>
> でもライブラリ側で制限があるんであれば、結局普通には使うことができない
> ということですよね。

普通というのがどの程度かということによりますが、fd_set を動的に確保する方法は
NetBSD のマニュアルには載っていて、基本的にはそれにそった形です。
(BUGS section なのがなんですが)

そして、そのやりかたについて考えてみると、fd_set の中身が bitmap であ
り、カーネルに FD_SETSIZE の制限がないのであれば動くであろうことが期待
できます。

> select() で FD_SETSIZE 以上のファイル記述子を扱う方法というのが公式に
> 無い以上、あくまでも select() でやろうとしたら、各OS毎の実装に依存した 
> select() の制限を迂回するような仕組みを Ruby 内に実装しないといけなく
> なるような気がするんですが、杞憂でしょうか。

poll に具体的な利点があれば poll を使ったほうがいいとは思います。しか
し、カーネルに FD_SETSIZE の制限があるか、fd_set の中身が bitmap でな
い場合で、現状 poll を使って救える環境が思い当たりません。

poll の利点が具体的にあれば変えたほうがいいと思います。でも、現時点で
見当たらないのであれば、見つかるまで select でいいんじゃないでしょうか。

> poll() がない環境(というのがどういうのかは私は知らないんですが)では、
> そもそも FD_SETSIZE 以上のファイルを作れないように制限しちゃうとかでも
> いいんじゃないでしょうか。SIGSEGV で落ちるよりはマシだと思います。
>
> ・ poll() がある環境:
>    select() ではなく poll() を使う。
>
> ・ poll() がない環境:
>    open/socket/pipe 等で FD_SETSIZE 以上のファイル記述子が生成された場
>    合は、Errno::EMFILE 例外にする。
>
> というような感じではどうでしょう？

環境によって実装を変えるのは、避けられるのであれば避けたほうがいいと思
います。開発者の手元で使用されないコードは壊れたときに気がつくのが遅れ
ますし、問題があったときの再現実験や修正も厄介です。

そのような面倒事は、本当に必要な状況が確認されるまで導入を遅らせたほう
がいいんじゃないでしょうか。
-- 
[田中 哲][たなか あきら][Tanaka Akira]