Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: auspex!guy@uunet.uu.net (Guy Harris)
Newsgroups: comp.sys.sun
Subject: Re: "select" (was: Re: Shared libraries linker error)
Keywords: SunOS
Message-ID: <1059@auspex.UUCP>
Date: 6 Mar 89 00:52:16 GMT
References: <615@dutrun.UUCP> <8901290118.AA21121@csli.Stanford.EDU> <998@auspex.UUCP>
Sender: usenet@rice.edu
Organization: Auspex Systems, Santa Clara
Lines: 17
Approved: Sun-Spots@rice.edu
Original-Date: 22 Feb 89 19:23:59 GMT
X-Sun-Spots-Digest: Volume 7, Issue 182, message 8 of 17

>...it may well have *encouraged* the use of "getdtablesize()", which
>is unfortunate. 

For more reasons than just "it causes your program not to work if your
system is upgraded to support more than 64 file descriptors."  Note that
even if you *do* use "fd_set"s, 4.3BSD-style, if you are using no file
descriptor larger than 31, you're causing the kernel to copy up to 3
32-bit words more than it has to if you use "getdtablesize()" as the
argument.  "getdtablesize()" in 4.3BSD, and in SunOS 4.0 and some other
systems, returns 64, which tells the "select" code that it has to copy 64
bits, or 8 bytes, worth of "fd_set".  If the largest file descriptor you
use is 31 or less, the file descriptor set fits in 4 bytes, so the other 4
bytes are copied into and out of the kernel unnecessarily.

Moral: don't use "getdtablesize()" in "select"; instead, figure out what
the largest file descriptor number you're using is, and pass that number
plus 1 as the first argument to "select".