Date: Sun, 4 Jul 1999 18:03:07 -0700 (PDT) From: Archie Cobbs <archie@whistle.com> To: cmsedore@mailbox.syr.edu (Christopher Sedore) Cc: peter@netplex.com.au, green@unixhelp.org, jlemon@americantv.com, wayne@crb-web.com, hackers@FreeBSD.ORG Subject: Re: poll() vs select() Message-ID: <199907050103.SAA51932@bubba.whistle.com> In-Reply-To: <Pine.SOL.4.10.9907041349400.28301-100000@rodan.syr.edu> from Christopher Sedore at "Jul 4, 99 02:00:56 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Christopher Sedore writes: > > 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. A new, faster event notification system would be great. But don't forget to include *all* events, not just file descriptor readability/writability. I.e., signal delivery, child exit notification, maybe even support for an arbitrary number of (independent) timers. And make the events independent from each other -- to avoid problems like when an application completely hangs for 90 seconds when it calls gethostbyname(). <rant> I've seen a zillion programs that have had to manually solve the problems caused by UNIX's lack of a unified event notification system. Eg., ppp(8) has its own timer library, etc. See also bind's event library. What a shameful waste/duplication of effort.. Really the underlying problem is that UNIX (originally) did not have any lightweight threads and options for IPC were (and still are) limited. This is one of the reasons I prefer programming in Java, even if it's slower. </rant> -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com 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?199907050103.SAA51932>