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 > 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? You can do much the same thing by using aio functions. I do this now with an added syscall aio_waitcomplete, which allows a process to sleep waiting for the next aio operation to finish. If more work was done on the aio routines to improve their performance (the existing ones are better than select() when you exceed about 40 descriptors), they would be faster than poll or select, and could function in a similar fashion to the event queue scheme above. I've only had about 140 or so connections open in my experiments, but aio has no trouble with these, to the point where my switched 100Mb line is the bottleneck. I experiment more with NNTP than HTTP, though I have toyed with the idea of hacking an existing web server to use aio. I like the event queue idea, but I'd like it for aio completions rather than an enhanced select() function. All IMHO, -Chris To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
