LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Michael Kerrisk <mtk.manpages@googlemail.com>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: David Schwartz <davids@webmaster.com>,
dada1@cosmosbay.com, "Chris \"?\" Heath" <chris@heathens.co.nz>,
"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
linux-man@vger.kernel.org
Subject: Re: epoll design problems with common fork/exec patterns
Date: Tue, 26 Feb 2008 16:13:43 +0100 [thread overview]
Message-ID: <47C42CA7.4030607@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0710291147180.3387@alien.or.mcafeemobile.com>
Davide Libenzi wrote:
> On Sun, 28 Oct 2007, David Schwartz wrote:
>
>> Eric Dumazet wrote:
>>
>>> Events are not necessarly reported "by descriptors". epoll uses an opaque
>>> field provided by the user.
>>>
>>> It's up to the user to properly chose a tag that will makes sense
>>> if the user
>>> app is playing dup()/close() games for example.
>> Great. So the only issue then is that the documentation is confusing. It
>> frequently uses the term "fd" where it means file. For example, it says:
>>
>> Q1 What happens if you add the same fd to an
>> epoll_set
>> twice?
>>
>> A1 You will probably get EEXIST. However, it is
>> possible
>> that two threads may add the same fd twice. This is
>> a
>> harmless condition.
>>
>> This gives no reason to think there's anything wrong with adding the same
>> file twice so long as you do so through different descriptors. (One can
>> imagine an application that does this to segregate read and write operations
>> to avoid a race where the descriptor is closed from under a writer due to
>> handling a fatal read error.) Obviously, that won't work.
>
> I agree, that is confusing. However, you can safely add two different file
> descriptors pointing to the same file*, with different event masks, and
> that will work as expected.
So can I summarize what I understand:
a) Adding the same file descriptor twice to an epoll set will cause an
error (EEXIST).
b) In a separate message to linux-man, Chris Heath says that two threads
*can't* add the same fd twice to an epoll set, despite what the existing
man page text says. I haven't tested that, but it sounds to me as though
it is likely to be true. Can you comment please Davide?
c) It is possible to add duplicated file descriptors referring to the same
underlying open file description ("file *"). As you note, this can be a
useful filtering technique, if the two file descriptors specify different
masks.
Assuming that is all correct, for man-pages-2.79, I've reworked the text
for Q1/A1 as follows:
Q1 What happens if you add the same file descriptor
to an epoll set twice?
A1 You will probably get EEXIST. However, it is pos-
sible to add a duplicate (dup(2), dup2(2),
fcntl(2) F_DUPFD, fork(2)) descriptor to the same
epoll set. This can be a useful technique for
filtering events, if the duplicate file descrip-
tors are registered with different events masks.
Seem okay Davide?
Cheers,
Michael
PS I've trimmed the part of this thread about Q6/A6, since I dealt with
that in another thread ("epoll and shared fd's").
--
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
next prev parent reply other threads:[~2008-02-26 15:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-27 6:22 Marc Lehmann
2007-10-27 8:23 ` Eric Dumazet
2007-10-27 8:51 ` Marc Lehmann
2007-10-27 9:22 ` Eric Dumazet
2007-10-27 9:34 ` Marc Lehmann
2007-10-27 10:23 ` Eric Dumazet
2007-10-27 10:46 ` Marc Lehmann
2007-10-27 16:59 ` Davide Libenzi
2007-10-27 17:38 ` Willy Tarreau
2007-10-27 18:01 ` Davide Libenzi
2007-10-29 22:36 ` Mark Lord
2007-10-28 4:47 ` David Schwartz
2007-10-28 9:33 ` Eric Dumazet
2007-10-28 21:04 ` David Schwartz
2007-10-29 18:55 ` Davide Libenzi
2008-02-26 15:13 ` Michael Kerrisk [this message]
2008-02-26 18:51 ` Davide Libenzi
2008-02-27 1:30 ` Chris "ク" Heath
2008-02-27 19:35 ` Davide Libenzi
2008-02-28 13:12 ` Michael Kerrisk
2008-02-28 13:23 ` Michael Kerrisk
2008-02-28 19:34 ` Davide Libenzi
2008-02-28 19:23 ` Davide Libenzi
2008-02-29 15:46 ` Michael Kerrisk
2008-02-29 19:19 ` Davide Libenzi
2008-02-29 19:54 ` Michael Kerrisk
2008-03-02 15:11 ` Sam Varshavchik
2008-03-02 21:44 ` Davide Libenzi
2007-10-28 18:48 ` Davide Libenzi
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=47C42CA7.4030607@gmail.com \
--to=mtk.manpages@googlemail.com \
--cc=chris@heathens.co.nz \
--cc=dada1@cosmosbay.com \
--cc=davidel@xmailserver.org \
--cc=davids@webmaster.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-man@vger.kernel.org \
--subject='Re: epoll design problems with common fork/exec patterns' \
/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
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).