LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
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: 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 [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
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
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=20071027085125.GC12326@schmorp.de \
--to=linux-kernel@tst.eu \
--cc=dada1@cosmosbay.com \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@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).