LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Davide Libenzi <davidel@xmailserver.org>
To: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: =?X-UNKNOWN?Q?Chris_=22=A5=AF=22_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 11:23:21 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0802281106050.7660@alien.or.mcafeemobile.com> (raw)
In-Reply-To: <cfd18e0f0802280512q43a457d0sc9a8dc83c51e8e1c@mail.gmail.com>

On Thu, 28 Feb 2008, Michael Kerrisk wrote:

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

Have you ever tried to think what it means for different *processes* 
sharing a single epoll fd and doing epoll_wait() over it?
Most common case is a single event fetch thread plus dispatch. Going to 
epoll_wait() over a single epoll fd from many *threads* is very much 
possible, but requires care (news at 11, system software development 
requires care too).
Sharing a single epoll fd (by the means of any process sharing it doing 
add/wait) from different *processes* makes almost no sense at all.
"a child process cannot add the duplicate file descriptor to the epoll 
set" ... how do you expect the parent (that doesn't even have the new fd 
mapped) to react to such events?
If the next question is "But then why we made the epoll fd inheritable?", 
the answer is, because it makes sense in many cases for a parent to hand 
over an fd set to a 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.

I think we already went over this, and I think I clearly explained you the 
reasons of not hooking into sys_close.



- Davide



  parent reply	other threads:[~2008-02-28 19: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
2008-02-28 19:34                           ` Davide Libenzi
2008-02-28 19:23                         ` Davide Libenzi [this message]
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=Pine.LNX.4.64.0802281106050.7660@alien.or.mcafeemobile.com \
    --to=davidel@xmailserver.org \
    --cc=chris@heathens.co.nz \
    --cc=dada1@cosmosbay.com \
    --cc=davids@webmaster.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@googlemail.com \
    --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).