Subject: Re: default maximum number of open file descriptors too small?
To: John Kohl <firstname.lastname@example.org>
From: Bakul Shah <email@example.com>
Date: 11/26/1995 21:13:51
> But even if you increase FD_SETSIZE for your own program's internals,
> you have to worry about libraries which use a fixed FD_SETSIZE and
> manipulate fd_sets using descriptors beyond the FD_SETSIZE range. This
> often makes for hard to find stack-twiddling corruption!
I am aware that a completely clean solution is not possible
at this point but most programs that need large set size
usually don't rely on such library routines, preferring to
roll their own. As long the number of significant fds
(nfds) is communicated and a routine touching argument fd
sets is careful to access only the first nfds bits (rounded
up to the next sizeof (long) boundary bytes), different
FD_SETSIZE definitions are not a problem.
Right now you can define FD_SETSIZE to something other than
the default and get in trouble with library routines relying
on the default definition so fixing select won't break
anything new. Basically fdset_t should've never existed.
It pains me to say that winsock (on NT & Windows) does at
least this right. So do IRIX and Solaris. BSDI, Linux,
FreeBSD, older SunOS don't.