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
> [EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
