From owner-freebsd-hackers Thu Mar 13 23:20: 0 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E7C237B404 for ; Thu, 13 Mar 2003 23:19:58 -0800 (PST) Received: from cirb503493.alcatel.com.au (c18609.belrs1.nsw.optusnet.com.au [210.49.80.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0245043F93 for ; Thu, 13 Mar 2003 23:19:57 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.6/8.12.5) with ESMTP id h2E7JtiM009994; Fri, 14 Mar 2003 18:19:55 +1100 (EST) (envelope-from jeremyp@cirb503493.alcatel.com.au) Received: (from jeremyp@localhost) by cirb503493.alcatel.com.au (8.12.6/8.12.5/Submit) id h2E7JtSo009993; Fri, 14 Mar 2003 18:19:55 +1100 (EST) Date: Fri, 14 Mar 2003 18:19:55 +1100 From: Peter Jeremy To: David Cuthbert Cc: hackers@FreeBSD.ORG Subject: Re: first parameter to select Message-ID: <20030314071954.GA9896@cirb503493.alcatel.com.au> References: <3E702BCC.3030208@kanga.org> <20030313083710.GA8225@cirb503493.alcatel.com.au> <3E70D561.1080001@kanga.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E70D561.1080001@kanga.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message