On Thu, Mar 13, 2003 at 02:00:49PM -0500, David Cuthbert wrote: >Peter Jeremy wrote: >>In virtually all cases, poll() will need to copy more data in and out >>of the kernel then select() would. Likewise, in virtually all cases, >>select() will need to scan more file descriptors than poll() does. >>The overall performance comes down to the relative cost of copying >>data vs testing bits. > >Not sure what you mean by virtually all cases. > >Given that a poll() descriptor is 12 bytes and fd_set is usually at >least 128 bytes (does select() copy the entire fd_set? I believe this >is the case, but don't have access to the source atm), the savings kicks >in at 12 descriptors.
The default fd_set size if 128 bytes - but this can be over-ridden at compile time. Select() only copies nfd bits (rounded up to a 32-bit boundary). There is no upper limit on nfd. Working out the data copy savings is difficult because the amount of data select() copies is defined by nfd (ie the highest FD number referenced) and the number of masks passed in (exception, write, read). It is independent of the number of FDs to be examined. The data copied in/out by poll() is 8 bytes per FD to be examined. It you need to select on read+write+except for a single FD, or need to select on few high-numbered FDs, poll() will copy less data. In all other cases, select() will copy less data. For small amounts of data, the copyin()/copyout() overheads will outweigh the actual copying. Once you're in the kernel, poll() can just walk along the array, checking each FD, whereas select() needs to check each bit from 0 to nfd-1 in each fd_set passed - though it can quickly skip high 0's in each long. >I'd still argue that, when porting a program across platforms, the >behaviour of select() is likely to be more consistent than poll(), >usually (always?) in the cases where something unusual has occurred on a >descriptor. Probably. I know Tru64 incorrectly sets bits in poll() revents when a socket is closed by the peer. I said poll() was blessed by SVID, I didn't say the implementations were actually consistent :-). Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
