All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Kegel <dank@alumni.caltech.edu>
To: John Gardiner Myers <jgmyers@netscape.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Readiness vs. completion (was: Re: Linux's implementation ofpoll()not scalable?)
Date: Mon, 30 Oct 2000 11:18:20 -0800	[thread overview]
Message-ID: <39FDC97C.456478E1@alumni.caltech.edu> (raw)
In-Reply-To: <39FCC2B8.DA281B4C@alumni.caltech.edu> <39FDC42A.CD9C3D12@netscape.com>

John Gardiner Myers wrote:
> 
> Dan Kegel wrote:
> > IMHO you're describing a situation where a 'completion notification event'
> > (as with aio) would be more appropriate than a 'readiness notification event'
> > (as with poll).
> 
> I've found that I want both types of events, preferably through the same
> interface.  

That's good to know.

> To provide a "completion notification event" interface on
> top of an existing nonblocking interface, one needs an "async poll"
> mechanism with edge-triggered events with no event coalescing.

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?
 
> You are correct in recognizing NT completion ports from my description.
> While the NT completion port interface is ugly as sin, it gets a number
> of performance issues right.
> 
> > And, come to think of it, network programmers usually can be categorized
> > into the same two groups :-)  Each style of programming is an acquired taste.
> 
> I would say that the "completion notification" style is a paradigm
> beyond the "readiness notification" style.  I started with the select()
> model of network programming and have since learned the clear
> superiority of the "completion notificatin" style.

Both seem to have their place, and deserve good support, IMHO.

- Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-10-31  7:12 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   ` Dan Kegel [this message]
2000-10-30 20:44     ` Readiness vs. completion (was: Re: Linux's implementationofpoll()not scalable?) John Gardiner Myers

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=39FDC97C.456478E1@alumni.caltech.edu \
    --to=dank@alumni.caltech.edu \
    --cc=jgmyers@netscape.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.