From: Dan Kegel <dank@alumni.caltech.edu>
To: "Eric W. Biederman" <ebiederm@biederman.org>
Cc: Helge Hafting <helgehaf@idb.hist.no>,
linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@transmeta.com>
Subject: Re: Linux's implementation of poll() not scalable?
Date: Thu, 26 Oct 2000 09:20:24 -0700 [thread overview]
Message-ID: <39F859C7.FC0A726F@alumni.caltech.edu> (raw)
In-Reply-To: <Pine.LNX.4.10.10010241121340.1704-100000@penguin.transmeta.com> <39F61766.FC5D2D81@alumni.caltech.edu> <39F6A412.DE378865@idb.hist.no> <39F7054C.72FB3EA8@alumni.caltech.edu> <m1aebs9i74.fsf@frodo.biederman.org>
"Eric W. Biederman" wrote:
>
> Dan Kegel <dank@alumni.caltech.edu> writes:
> > It's harder to write correct programs that use edge-triggered events.
>
> Huh? The race between when an event is reported, and when you take action
> on it effectively means all events are edge triggered.
Nope. With any of these interfaces, whether level or edge, the app must
treat all the events as hints, and be prepared for them to be wrong.
That's why code that uses poll() tends to use nonblocking sockets.
No matter what you do, you can't get away from that. Consider
accepting a connection. Poll or whatever tells you a listening socket
is ready for you to call accept(). Before you do, the other end sends
an RST. Consequence: app must be prepared for a readiness event to be wrong.
cf. http://boudicca.tux.org/hypermail/linux-kernel/2000week44/0616.html
This is orthogonal to the question of whether edge or level triggering
is easier to write code for, I think.
> So making the interface clearly edge triggered seems to be a win for
> correctness.
With level-triggered interfaces like poll(), your chances
of writing a correctly functioning program are higher because you
can throw events away (on purpose or accidentally) with no consequences;
the next time around the loop, poll() will happily tell you the current
state of all the fd's.
With edge-triggered interfaces, the programmer must be much more careful
to avoid ever dropping a single event; if he does, he's screwed.
This gives rise to complicated code in apps to remember the current
state of fd's in those cases where the programmer has to drop events.
And there are many cases like that; see
http://boudicca.tux.org/hypermail/linux-kernel/2000week44/0529.html and
http://boudicca.tux.org/hypermail/linux-kernel/2000week44/0592.html
for examples.
Better to let apps ask the kernel for the current state of each socket if
they want, is what I say. This reduces the amount of code and effort needed
to write many apps, *and makes migrating legacy apps to high-performance
interfaces easier*.
For new apps that are willing to maintain the state
themselves, by all means, provide an edge-oriented interface, too.
It's probably better if your code is manly enough to handle it.
- 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/
next parent reply other threads:[~2000-10-26 16:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.10.10010241121340.1704-100000@penguin.transmeta.com>
[not found] ` <39F61766.FC5D2D81@alumni.caltech.edu>
[not found] ` <39F6A412.DE378865@idb.hist.no>
[not found] ` <39F7054C.72FB3EA8@alumni.caltech.edu>
[not found] ` <m1aebs9i74.fsf@frodo.biederman.org>
2000-10-26 16:20 ` Dan Kegel [this message]
2000-10-26 16:44 ` Linux's implementation of poll() not scalable? Linus Torvalds
2000-10-26 19:51 ` Jim Gettys
2000-10-26 21:48 ` Dan Kegel
2000-10-27 13:56 ` Chris Swiedler
2000-10-27 0:47 ` Dan Kegel
[not found] <local.mail.linux-kernel/39F8D09B.F55AD0FD@alumni.caltech.edu>
[not found] ` <local.mail.linux-kernel/Pine.LNX.4.10.10010260936330.2460-100000@penguin.transmeta.com>
2000-10-27 1:35 ` Jonathan Lemon
2000-10-28 0:46 John Gardiner Myers
[not found] <39F529CC.2538300@alumni.caltech.edu>
2000-10-30 22:22 ` Mike Jagdis
2000-11-01 16:09 ` Dan Kegel
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=39F859C7.FC0A726F@alumni.caltech.edu \
--to=dank@alumni.caltech.edu \
--cc=ebiederm@biederman.org \
--cc=helgehaf@idb.hist.no \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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