Date: Sun, 4 Jul 1999 13:51:28 +0930 From: Greg Lehey <grog@lemis.com> To: Jonathan Lemon <jlemon@americantv.com> Cc: Peter Wemm <peter@netplex.com.au>, "Brian F. Feldman" <green@unixhelp.org>, wayne@crb-web.com, hackers@FreeBSD.ORG Subject: Re: poll() vs select() Message-ID: <19990704135128.U709@freebie.lemis.com> In-Reply-To: <19990703231029.08379@right.PCS>; from Jonathan Lemon on Sat, Jul 03, 1999 at 11:10:29PM -0500 References: <Pine.BSF.4.10.9907030058240.22384-100000@janus.syracuse.net> <19990704040435.35CD464@overcee.netplex.com.au> <19990703231029.08379@right.PCS>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 3 July 1999 at 23:10:29 -0500, Jonathan Lemon wrote: > On Jul 07, 1999 at 12:04:35PM +0800, Peter Wemm wrote: >> "Brian F. Feldman" wrote: >>> On Fri, 2 Jul 1999, Jonathan Lemon wrote: >>> >>>> In article <local.mail.freebsd-hackers/Pine.LNX.3.95.990702160538.27513C-10 >> 0000@crb.crb-web.com> you write: >>>>> now supports the select() and poll() system calls. My question is really >> one >>>>> of usage. Why would one us poll() over select()? Is select eventually go >> ing >>>>> to go away for some reason? >>>> >>>> select() as a user-level call will never go away; there is a large base >>>> of code that uses it. >>>> >>>> poll() is faster (it doesn't have to do bit twiddling), and it's interface >>>> is cleaner (it can report invalid fd's, something select() can't do). As >>>> its functionality is a superset of select()'s, it is used as the internal >>>> implementation for select(). >>> >>> Actually, select() doesn't require horrendous amounts of copyin()s, which >>> poll() does. So have you benchmarked the two? I'd expect select to be faster. >> >> Actually.. select() has three copyins and three copyouts per call. poll() >> has one copyin and one copyout per call. >> >> Now what I particular like is the event queue system that David Filo put >> together for Yahoo. In a nutshell you create a queue (a fd), and then >> register the descriptors you want to monitor with the queue. You then run >> an accept()-like loop where the accept returns the fd number that has met >> the conditions you asked for. For example, if you wanted to know if fd >> number 4251 becomes readable, then the accept would return 4251. This has >> potential to work across multiple processes sharing a queue so that events >> could get round robined or whatever. The other good part is that it >> maintains the state and lists persistantly and doesn't have to keep copying >> it to/from the kernel. It handles 50,000 to 100,000 connections without >> too much trouble. You can still use this with select as the queue fd >> becomes readable when there is an event waiting for your process. This sounds rather like what Tandem did in its TOS^H^H^HGuardian^H^H^H^H^H^H^H^HNonStop Kernel operating system. At the user level, you had the choice of calling awaitio (-1), which would return the next completion on any fd, or awaitio (4251), which would return information on that specific fd. And of course you have the choice of blocking or not if the conditions aren't met. Of course, the performance implications of waiting on a specific fd are another issue. >> Is there interest in doing something like this in general? > > YES! As a matter of fact, I've done something similar to this already, > but instead of a queue, it's a variant of poll which passes in and out > "change lists"; a list of fd's which have had status changes since the > last call. I've been trying to bring it up for discussion on the -arch > list, but it's been dead. (I think it was just fixed recently). Did you see the presentation "A scalable and explicit event delivery mechanism for UNIX" at USENIX? It sounded quite interesting. Page 253 of the proceedings. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990704135128.U709>