From: Marc Lehmann <linux-kernel@tst.eu>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: linux-kernel@vger.kernel.org, Davide Libenzi <davidel@xmailserver.org>
Subject: Re: epoll design problems with common fork/exec patterns
Date: Sat, 27 Oct 2007 10:51:25 +0200 [thread overview]
Message-ID: <20071027085125.GC12326@schmorp.de> (raw)
In-Reply-To: <4722F575.8080204@cosmosbay.com>
On Sat, Oct 27, 2007 at 10:23:17AM +0200, Eric Dumazet <dada1@cosmosbay.com> wrote:
> > In this case, the parent process works fine until the child closes fds,
> > after which the fds become unarmed in the parent too. This works as
>
> I have no idea what exact problem you have.
Well, I explained it rather succinctly, I think. If you tell me whats unclear
I can explain...
> But if the child closes some
> file descriptor that were 'cloned' at fork() time, this only decrements a
> refcount, and definitely should not close it for the 'parent'.
It doesn't. It removes it from the epoll set, though, so the parent will not
receive events for that fd anymore.
> I have some apps that are happily using epoll() and fork()/exec() and have
The problem I described is fork/close/exec. close being the explicit
syscall.
> no problem at all. I usually use O_CLOEXEC so that all close() are done at
> exec() time without having to do it in a loop. epoll continues to work as
> expected in the parent process.
This is because epoll doesn't behave like documented: It removes the fd
from the parents epoll set only on an explicit close() syscall, not on an
implicit close from exec.
> >fd sets. This would explain the behaviour above. Unfortunately (or
> >fortunately?) this is not what happens: when the fds are being closed by
> >exec or exit, the fds do not get removed from the epoll set.
>
> at exec() (granted CLOEXEC is asserted) or exit() time, only the refcount
> of each file is decremented. Only if their refcount becomes NULL, files are
> then removed from epoll set.
Yes. But thats obviously not the only way to close fds.
> >Is epoll really designed to be so incompatible with the most commno fork
> >patterns? Shouldn't epoll do refcounting, as is commonly done under
> >Unix? As the fd space is not shared between rpocesses, why does epoll
> >try? Shouldn't the epoll information be copied just like the fd table
> >itself, memory, and other resources?
>
> Too many questions here, showing lack of understanding.
You already said you don't the problem. No need to get insulting :(
> epoll definitly is not useless. It is used on major and critical apps.
> You certainly missed something.
Well, it behaves like documented, which is the problem. You admit you
don't understand the problem or the documentation, so again, no need to
insult me.
> Please provide some code to illustrate one exact problem you have.
// assume there is an open epoll set that listens for events on fd 5
if (fork () = 0)
{
close (5);
// fd 5 is now removed from the epoll set of the parent.
_exit (0);
}
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ pcg@goof.com
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
next prev parent reply other threads:[~2007-10-27 8:49 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-27 6:22 epoll design problems with common fork/exec patterns Marc Lehmann
2007-10-27 8:23 ` Eric Dumazet
2007-10-27 8:51 ` Marc Lehmann [this message]
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
[not found] ` <Pine.LNX.4.64.0710291147180.3387-GPJ85BhbkB8RepQJljzAVbITYcZ0+W3JAL8bYrjMMd8@public.gmane.org>
2008-02-26 15:13 ` Michael Kerrisk
2008-02-26 15:13 ` Michael Kerrisk
[not found] ` <47C42CA7.4030607-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-02-26 18:51 ` Davide Libenzi
2008-02-26 18:51 ` Davide Libenzi
[not found] ` <Pine.LNX.4.64.0802261049040.27243-GPJ85BhbkB8RepQJljzAVbITYcZ0+W3JAL8bYrjMMd8@public.gmane.org>
2008-02-27 1:30 ` Chris "ク" Heath
2008-02-27 1:30 ` Chris "ク" Heath
[not found] ` <1204075804.5238.7.camel-DBi1IKlRe8YXiSwHZUBl+UgmxNRb6L7S@public.gmane.org>
2008-02-27 19:35 ` Davide Libenzi
2008-02-27 19:35 ` Davide Libenzi
[not found] ` <Pine.LNX.4.64.0802271131180.377-GPJ85BhbkB8RepQJljzAVbITYcZ0+W3JAL8bYrjMMd8@public.gmane.org>
2008-02-28 13:12 ` Michael Kerrisk
2008-02-28 13:12 ` Michael Kerrisk
[not found] ` <cfd18e0f0802280512q43a457d0sc9a8dc83c51e8e1c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-28 13:23 ` Michael Kerrisk
2008-02-28 13:23 ` Michael Kerrisk
[not found] ` <cfd18e0f0802280523p1bdacfc5s274387f8280238c8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-28 19:34 ` Davide Libenzi
2008-02-28 19:34 ` Davide Libenzi
2008-02-28 19:23 ` Davide Libenzi
2008-02-28 19:23 ` Davide Libenzi
[not found] ` <Pine.LNX.4.64.0802281106050.7660-GPJ85BhbkB8RepQJljzAVbITYcZ0+W3JAL8bYrjMMd8@public.gmane.org>
2008-02-29 15:46 ` Michael Kerrisk
2008-02-29 15:46 ` Michael Kerrisk
[not found] ` <cfd18e0f0802290746p3cb7efc9j72394cd77ff37829-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-02-29 19:19 ` Davide Libenzi
2008-02-29 19:19 ` Davide Libenzi
2008-02-29 19:54 ` Michael Kerrisk
2008-03-02 15:11 ` Sam Varshavchik
2008-03-02 15:11 ` Sam Varshavchik
[not found] ` <cone.1204470717.369031.30230.500-lO+bjgoT4TKm14v+eVDVcBDJ/jce7dRH@public.gmane.org>
2008-03-02 21:44 ` Davide Libenzi
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=20071027085125.GC12326@schmorp.de \
--to=linux-kernel@tst.eu \
--cc=dada1@cosmosbay.com \
--cc=davidel@xmailserver.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.