> 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.
Niels Provos is working on a "hinting" poll() for Linux that uses a system
very similar to this where network devices register themselves with
poll(), and provide hints when they are ready for I/O. Niels, maybe you
can describe your work?
> > 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.
that's one of many issues that worries me about aio_. i think you should
definitely try writing a server with aio_ to see what problems you run
into. i have lots of questions about how usable is aio_ for real
applications.
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- 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/