On Jun 2, 2006, at 12:29 PM, Greg Hudson wrote:
> On Fri, 2006-06-02 at 10:35 -0400, Michael Sweet wrote:
>> Recent versions of glibc (>= 2.3.2 IIRC) *do* limit FDSET_SIZE to
>> 1024, even though the kernel interface has not such limit. The
>> response I've been given from the glibc folks is that "we should be
>> using poll() instead"...
>
> select has to have a fixed limit because of the nature of its
> interface.
> fd_set cannot be a dynamically allocated structure because you have to
> be able to copy it with assignment
Why? No code I have ever seen does this...
> (plus, there's no deallocation
> method), so it must have a fixed size. A limit of 1024 means each
> fd_set takes up 128 bytes; if that limit were upped by default to
> something larger like 32K, each fd_set would take up 4K of space,
> probably on the stack, which would start to cause problems in
> multi-threaded programs.
Every OS other than Linux allows select() to work with an arbitrary
number of file descriptors; even the Linux kernel allows it, just not
glibc.
> poll has a saner interface, and isn't subject to this problem.
That's really just a matter of opinion, and not one that I share.
Try managing and array of thousands of poll entries sometime, and
then compare the efficiency of a bit test vs. scanning an array
after the fact... You already have to track your connections
separately, but with poll you need to be able to lookup those
connections via file descriptor *fast*. Manage several different
types of connections and you add yet another complication. Finally,
some systems don't support or work well with poll(), so you need to
support both select() and poll() now...
This is just an arbitrary change to glibc for a bug that didn't
exist - glibc is artificially limiting select() for no good reason.
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 3 14:13:29 2006