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 > 0...@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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
