In BSD, you can define FD_SETSIZE to some higher value than 1024 prior to
the inclusion of <sys/types.h>. The only thing that FD_SETSIZE does is
define the default capacity of the FD_SET; the kernel is quite happy to
access a larger fd_set.
Doubling FD_SETSIZE to 2048 would increase the fd_set by a whole 128
bytes. Oh, the horror! How can we possibly afford it? [Excuse the
venomous sarcasm, but this sort of baby-computer thinking has been an
ongoing problem with UNIX type systems.]
In Linux, it is messier. FD_SETSIZE is defined by __FD_SETSIZE, which
in turn is defined in
/usr/include/bits/typesizes.h
and
/usr/include/bits/posix_types.h
The comments in posix_types.h are definitely worth reading, as they betray
more baby-computer thinking. Worse, there is a __kernel_fd_set definition
which implies that the Linux kernel is incapable of handling programs
which are compiled with larger definitions of FD_SET.
Even more annoying, Linux has a #define for the maximum file descriptor
value -- NR_OPEN -- and there is no reason other than cranium-up-rectum
disease for FD_SETSIZE to be any other value.
I didn't investigate further. For some reason known only to the
developers of Linux, the includes and their mechanisms are incredibly
arcane. Try looking for the errno definitions -- you have to go through
multiple levels of #include before you find them.
So, I don't know if an application program on Linux can define a larger
fd_set size that the kernel subsequently can use. If not, then the only
fix is to change tcp_unix.c to use poll() instead of select(), and hope
that you never have to build c-client on a system that has select() but
not poll().
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
