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: "Chris \"ク\" Heath" <chris@heathens.co.nz>,
	"David Schwartz" <davids@webmaster.com>,
	dada1@cosmosbay.com,
	"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: Thu, 28 Feb 2008 14:23:34 +0100	[thread overview]
Message-ID: <cfd18e0f0802280523p1bdacfc5s274387f8280238c8@mail.gmail.com> (raw)
In-Reply-To: <cfd18e0f0802280512q43a457d0sc9a8dc83c51e8e1c@mail.gmail.com>

On Thu, Feb 28, 2008 at 2:12 PM, Michael Kerrisk
<mtk.manpages@googlemail.com> wrote:
>
> On Wed, Feb 27, 2008 at 8:35 PM, Davide Libenzi <davidel@xmailserver.org> wrote:
>  > On Tue, 26 Feb 2008, Chris "ã~B¯" Heath wrote:
>  >
>  >  > On Tue, 2008-02-26 at 10:51 -0800, Davide Libenzi wrote:
>  >  > >
>  >
>  > > > Yes, you can't add the same fd twice. Think about a DB where "file*,fd" is
>  >  > > the key.
>  >  >
>  >  > To clarify, the key appears to be file* plus the user-space integer that
>  >  > represents the fd.
>  >
>  >  Yes, that's what I said.
>  >
>  >  > > > 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?
>  >  > >
>  >  > > Looks sane to me.
>  >  >
>  >  > I think fork(2) should not be in the above list.  fork(2) duplicates the
>  >  > kernel's fd, but the user-space integer that represents the fd remains
>  >  > the same, so you will get EEXIST if you try to add the fd that was
>  >  > duplicated by fork.
>  >
>  >  Good catch, fork(2) should not be there.
>
>  Okay -- removed.
>
>  But it is an ugly inconsistency.  On the one hand, a child process
>  cannot add the duplicate file descriptor to the epoll set.  (In every
>  other case that I can think of , descriptors duplicated by fork have
>  similar semantics to descriptors duplicated by dup() and friends.)  On
>  the other hand, the very fact that the child has a duplicate of the
>  descriptor means that even if the parent closes its descriptor, then
>  epoll_wait() in the parent will continue to receive notifications for
>  that descriptor because of the duplicated descriptor in the child.
>
>  The choice of [file *, fd] as the key for epoll sets really does seem
>  unfortunate.  Keying on [pid, fd] would have given saner semantics, it
>  seems to me.  Obviously it can't be changed now though.


Davide,

with the earlier discussion in this thread in mind, I added a Q0/A0 to
epoll.7, just make the point about keys clear:


       Q0  What is the key used to distinguish the file descrip-
           tors in an epoll set?

       A0  The key is the combination  of  the  file  descriptor
           number  and  the open file description (also known as
           "open file handle", the kernel's internal representa-
           tion of an open file).

Does that seem okay?

Cheers,

Michael

-- 
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-28 13:23 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
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 [this message]
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=cfd18e0f0802280523p1bdacfc5s274387f8280238c8@mail.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).