Date: Sun, 4 Jul 1999 01:41:46 -0400 (EDT) From: "Brian F. Feldman" <green@FreeBSD.org> To: Peter Wemm <peter@netplex.com.au> Cc: "Brian F. Feldman" <green@unixhelp.org>, Jonathan Lemon <jlemon@americantv.com>, wayne@crb-web.com, hackers@FreeBSD.org Subject: Re: poll() vs select() Message-ID: <Pine.BSF.4.10.9907040140310.47486-100000@janus.syracuse.net> In-Reply-To: <19990704040435.35CD464@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 4 Jul 1999, 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.
>
But poll() copies in HUGE amounts of data compared to the few bytes for
thousands of FDs that select does.
> 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! That would not replace select() or poll(), but it would be awesome
to have!
>
> 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
>
Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
green@FreeBSD.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
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?Pine.BSF.4.10.9907040140310.47486-100000>