Dan Kegel wrote:
> If you have a top-notch completion notification event interface
> provided natively by the OS, though, does that get rid of the
> need for the "async poll" mechanism?

A top-notch completion notification event interface needs to be able to
provide "async poll" functionality.  There are some situations where an
application needs a completion notification event when an fd is readable
or writeable, but cannot supply buffers or data until after the event
arrives.

One of these situations is when the application is using a nonblocking
interface to an existing library.  When the library returns a
"wouldblock" condition, the application determines through the interface
(or the interface definition) which poll events need to occur before a
subsequent call to the library is likely to result in progress.  The
application then needs to schedule a completion event for when those
poll events occur.  The application does not know enough about the
library implementation to schedule async I/O and the library is not
written to use async I/O itself.

Another situation occurs when handling a large number of mostly idle
connections.  Consider a protocol for which a server receives one
command per half hour per connection.  A server process would want to
handle hundreds of thousands to millions of such connections.  If the
server were to use asynchronous read operations, then it would have to
allocate one input buffer per connection.  Better to instead use
asynchronous read poll operations, allocating buffers to connections
only when those connections have pending input.

This latter situation would be further improved by a variant of the
asynchronous read operation where the buffer is supplied by either the
event queue object or the caller to get_event(), but that's a separate
issue.