Date: Sat, 3 Jul 1999 23:10:29 -0500 From: Jonathan Lemon <jlemon@americantv.com> To: Peter Wemm <peter@netplex.com.au> Cc: "Brian F. Feldman" <green@unixhelp.org>, wayne@crb-web.com, hackers@FreeBSD.ORG Subject: Re: poll() vs select() Message-ID: <19990703231029.08379@right.PCS> In-Reply-To: <19990704040435.35CD464@overcee.netplex.com.au>; from Peter Wemm on Jul 07, 1999 at 12:04:35PM %2B0800 References: <Pine.BSF.4.10.9907030058240.22384-100000@janus.syracuse.net> <19990704040435.35CD464@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > 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). -- Jonathan 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?19990703231029.08379>