public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: John Gardiner Myers <jgmyers@netscape.com>
To: dank@alumni.caltech.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: Readiness vs. completion (was: Re: Linux's implementationofpoll()not scalable?)
Date: Mon, 30 Oct 2000 12:44:09 -0800	[thread overview]
Message-ID: <39FDDD99.BD1889BB@netscape.com> (raw)
In-Reply-To: <39FCC2B8.DA281B4C@alumni.caltech.edu> <39FDC42A.CD9C3D12@netscape.com> <39FDC97C.456478E1@alumni.caltech.edu>

[-- Attachment #1: Type: text/plain, Size: 1815 bytes --]



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.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 2147 bytes --]

      reply	other threads:[~2000-10-30 20:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-30  0:37 Readiness vs. completion (was: Re: Linux's implementation of poll() not scalable?) Dan Kegel
2000-10-30 18:55 ` Readiness vs. completion (was: Re: Linux's implementation of poll()not scalable?) John Gardiner Myers
2000-10-30 19:18   ` Readiness vs. completion (was: Re: Linux's implementation ofpoll()not scalable?) Dan Kegel
2000-10-30 20:44     ` John Gardiner Myers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39FDDD99.BD1889BB@netscape.com \
    --to=jgmyers@netscape.com \
    --cc=dank@alumni.caltech.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox