Re: problem/bug/limitation in uw-client-library

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
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw