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


  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).