From owner-freebsd-hackers Fri Mar 14 5:47: 7 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 20BD437B401 for ; Fri, 14 Mar 2003 05:47:05 -0800 (PST) Received: from mail.rdslink.ro (mail.rdslink.ro [193.231.236.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 6281E43FA3 for ; Fri, 14 Mar 2003 05:47:03 -0800 (PST) (envelope-from enache@rdslink.ro) Received: (qmail 8315 invoked from network); 14 Mar 2003 13:48:00 -0000 Received: from unknown (HELO ratsnest.hole) (10.100.0.123) by mail.rdslink.ro with SMTP; 14 Mar 2003 13:48:00 -0000 Received: from ratsnest.hole (localhost [127.0.0.1]) by ratsnest.hole (8.12.5/8.12.5) with ESMTP id h2EDlLgO000844; Fri, 14 Mar 2003 15:47:21 +0200 Received: (from adi@localhost) by ratsnest.hole (8.12.5/8.12.5/Submit) id h2EDlLCW000842; Fri, 14 Mar 2003 15:47:21 +0200 Date: Fri, 14 Mar 2003 15:47:21 +0200 From: Enache Adrian To: Peter Jeremy Cc: David Cuthbert , hackers@FreeBSD.ORG Subject: Re: first parameter to select Message-ID: <20030314134721.GA705@ratsnest.hole> References: <3E702BCC.3030208@kanga.org> <20030313083710.GA8225@cirb503493.alcatel.com.au> <20030313165018.GA703@ratsnest.hole> <20030314063516.GA9301@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030314063516.GA9301@cirb503493.alcatel.com.au> 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 Fri, Mar 14, 2003 at 05:35:16PM +1100, Peter Jeremy wrote: > On Thu, Mar 13, 2003 at 06:50:18PM +0200, Enache Adrian wrote: > >I have no benchmarks, but judging after the way things are implemented > >in the FreeBSD kernel, select() is definitely faster. > > Can you explain what leads you to make this statement please. But poll() swaps a _LOT_ more data between the kernel and userland ! > >Please someone explain me what is meant in select(2) by: > > > > If nfds is greater than the number of open files, select() is not guaran- > > teed to examine the unused file descriptors. For historical reasons, > > select() will always examine the first 256 descriptors. > > The second sentence appears to be an error. I can't find anything in > the current code (or previous versions) that suggests select() would > ever examine more than nfd FDs. The only reference to 256 is can find > is that FD_SETSIZE used to be 256 and select() used to return EINVAL if > nfd > FD_SETSIZE. It probably wants to say ( in a manner quite confusing for a non english speaker like me ) that select(2) won't bother to return EINVAL for bad file descriptors which are in the bitmaps and are both greater than the greatest open file descriptor and greater than 255. That's only half wrong. :-) select() won't bother to check them even if they are < 256. It's only the greatest open file descriptor that matters. -- from kern/sys_generic.c:751 - kern_select() if (nd > td->td_proc->p_fd->fd_nfiles) nd = td->td_proc->p_fd->fd_nfiles; /* forgiving; slightly wrong */ --- Take a look at this little program: ------------------------ #include #include int main() { fd_set set; FD_ZERO(&set); FD_SET(0,&set); FD_SET(20,&set); if (select(FD_SETSIZE,&set,0,0,0) == -1) err(1,"select"); return 0; } ------------------------ change 20 to 19 and select() will return EBADF. Linux will return EBADF even if you put FD_SETSIZE-1 there. I find FreeBSD's behaviour reasonable - and I wonder what 'historical' programs pass dummy, never opened fds to select() in the hope of getting EBADF in return. Regards Adi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message