Date: Mon, 3 Apr 1995 22:53:24 -0700 From: Bill Paul <wpaul> To: CVS-commiters, cvs-lib Subject: cvs commit: src/lib/libc/rpc rpc_dtablesize.c Message-ID: <199504040553.WAA04169@freefall.cdrom.com>
next in thread | raw e-mail | index | archive | help
wpaul 95/04/03 22:53:23 Modified: lib/libc/rpc rpc_dtablesize.c Log: 'Fix' for esoteric misfeature discovered while searching for another bug: select() returns EINVAL if you try to feed it a value of FD_SETSIZE greater that 256. You can apparently adjust this by specifying a larger value of FD_SETSIZE when configuring your kernel. However, if you set the maximum number of open file descriptors per process to some value greater than the FD_SETSIZE value that select() expects, many selects() within the RPC library code will be botched because _rpc_dtablesize() will return invalid numbers. This is to say that it will return the upper descriptor table size limit which can be much higher than 256. Unless select() is prepared to expect this 'unusually' high value, it will fail. (A good example of this can be seen with NIS enabled: if you type 'unlimit' at the shell prompt and then run any command that does NIS calls, you'll be bombarded with errors from clnttcp_create().) A temporary fix for this is to clamp the value returned by _rpc_dtablesize() at FD_SETSIZE (as defined in <sys/types.h> (256)). I suppose the Right Thing would be to provide some mechanism for select() to dynamically adjust itself to handle FD_SETSIZE values larger than 256, but it's a bit late in the game for that. Hopefully 256 file descriptors will be enough to keep RPC happy for now.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504040553.WAA04169>