Messages in this thread | | | Date | Fri, 14 May 1999 14:44:08 +0000 | From | Dan Kegel <> | Subject | /dev/poll vs. aio_ (was: Re: Proposal: Get rid of most accept mutex)calls on hybrid server.) |
| |
Dean Gaudet wrote: > (A person at Sun wrote:) > > As of Solaris 7 a scheme refered to as /dev/poll was implemented such that > > pollfd_t's are registered with the underlying FS (i.e. UFS, SOCKFS, ...) > > and the FS does asynchronous notification. The end result is that poll() > > now scales to tens of thousands of FDs per LWP (as well as a new API for > > /dev/poll such that you open /dev/poll and do write()s (to register a number > > of pollfd's) and read()s (to wait for, or in the case of nonblocking check > > for, pollfd event(s)), using the /dev/poll API memory is your only limit > > for scalability. > > Now that's real nice. I've been advocating this on linux kernel for a > long time. Say hello to completion ports the unix way. I'm assuming they > do the "right thing" and wake up in LIFO order, and allow you to read > multiple events at once.
I have yet to use aio_ or F_SETSIG, but reading ready fd's from /dev/poll makes more sense to me than listening for realtime signals from aio_, which according to http://www.deja.com/getdoc.xp?AN=366163395 can overflow, in which case the kernel sends a SIGIO to say 'realtime signals overflowed, better do a full poll'. I'm contemplating writing a server that uses aio_; that case kind of defeats the purpose of using aio_, and handling it sounds annoying and suboptimal.
/dev/poll would never overflow in that way.
- Dan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |