Date: Sun, 04 Jul 1999 12:04:35 +0800 From: Peter Wemm <peter@netplex.com.au> To: "Brian F. Feldman" <green@unixhelp.org> Cc: Jonathan Lemon <jlemon@americantv.com>, wayne@crb-web.com, hackers@FreeBSD.ORG Subject: Re: poll() vs select() Message-ID: <19990704040435.35CD464@overcee.netplex.com.au> In-Reply-To: Your message of "Sat, 03 Jul 1999 01:01:07 -0400." <Pine.BSF.4.10.9907030058240.22384-100000@janus.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"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?
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
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?19990704040435.35CD464>