From: Jamie Lokier <jamie@shareable.org>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Eric Varsanyi <e0216@foo21.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: epoll vs stdin/stdout
Date: Tue, 8 Jul 2003 13:34:21 +0100 [thread overview]
Message-ID: <20030708123421.GB14827@mail.jlokier.co.uk> (raw)
In-Reply-To: <Pine.LNX.4.55.0307071802360.3531@bigblue.dev.mcafeelabs.com>
Davide Libenzi wrote:
> > 2. When process A sends an fd to process B, the events will appear
> > in process B _iff_ the fd number in B happens to be the same
> > value as in process A. (Without your patch, the events will always
> > appear in process B).
> >
> > Furthermore, when process B dups the fd or passes it elsewhere,
> > events will appear if the new fd happens to be the same as the
> > original fd number in A.
> >
> > The only correct application code in this case is to use
> > EPOLL_CTL_DEL in A and EPOLL_CTL_ADD in B, although it is
> > confusing because you'll have programs which _sometimes_ work
> > without that.
>
> This is false.
Actually it's true :)
> Is like saying that :
> [...]
> is a memory leak ;)
Well, yeah :)
You'll have to document this loud and clear: anyone who closes, dup2s
over or passed an epoll-activated file descriptor _must_ use
EPOLL_CTL_DEL first, otherwise heisenbugs may eventually follow.
> > I guess what I'm saying is that hashing on fd number is quite simply
> > wrong. The fundamental object is the file *, that's how its meant to be.
>
> The architecture is all based on the file*, it is there that events shows
> up. The (file*, fd) key is a constraint.
Unfortunately I just thought of a real problem :(
What happens when process A sends (or forks) a dup of its fd 3 to
process B which also has it as fd 3, and both processes use epoll on
it? (This is a fairly common scenario, to have one process/thread
reading and the other writing a tty or socket). The two processes
will clash because they have the same (file *, fd) pair, yet there is
no way for them to know they are clashing.
With current epoll code this is a problem already, because keying on
(file *) alone is not enough. Unfortunately (file *,fd) key doesn't
fix this one.
-- Jamie
next prev parent reply other threads:[~2003-07-08 12:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-07 15:48 epoll vs stdin/stdout Eric Varsanyi
2003-07-07 18:57 ` Davide Libenzi
2003-07-07 19:47 ` Eric Varsanyi
2003-07-07 20:03 ` Jamie Lokier
2003-07-07 20:18 ` Miquel van Smoorenburg
2003-07-07 21:20 ` H. Peter Anvin
2003-07-07 22:11 ` Davide Libenzi
2003-07-08 0:24 ` Jamie Lokier
2003-07-08 0:23 ` Davide Libenzi
2003-07-07 22:12 ` Davide Libenzi
2003-07-07 23:26 ` Davide Libenzi
2003-07-08 0:32 ` Jamie Lokier
2003-07-08 0:32 ` Davide Libenzi
2003-07-08 0:52 ` Jamie Lokier
2003-07-08 1:13 ` Davide Libenzi
2003-07-08 12:34 ` Jamie Lokier [this message]
2003-07-08 13:51 ` Jamie Lokier
2003-07-08 15:20 ` Davide Libenzi
2003-07-08 15:46 ` Eric Varsanyi
2003-07-08 15:42 ` Davide Libenzi
2003-07-08 16:02 ` Eric Varsanyi
2003-07-08 17:06 ` Davide Libenzi
2003-07-08 18:40 ` Eric Varsanyi
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=20030708123421.GB14827@mail.jlokier.co.uk \
--to=jamie@shareable.org \
--cc=davidel@xmailserver.org \
--cc=e0216@foo21.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).