LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Marc Lehmann <linux-kernel@tst.eu>
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 12:23:52 +0200	[thread overview]
Message-ID: <472311B8.5080408@cosmosbay.com> (raw)
In-Reply-To: <20071027093424.GA31329@schmorp.de>

Marc Lehmann a écrit :
> On Sat, Oct 27, 2007 at 11:22:25AM +0200, Eric Dumazet <dada1@cosmosbay.com> wrote:
> 
>> If such a bug exists on your kernel, please fill a complete bug report, 
>> giving details.
> 
> As this behaviour is clearly documented in the epoll manpage, why do you
> think it is a bug? I think its fairly bad, but at least tis documented as
> the behaviour it should be:
> 
>     Q6     Will the close of an fd cause it to be removed from all epoll sets automatically?
>     A6     Yes.

Answer : epoll documentation cannot explain the full semantic of file 
descriptors, or difference between user side (file descriptors) and kernel 
side (files and fds)
Or should, since you had problems. But then, if the epoll documentation has to 
document the full Unix/Linux files semantic, nobody will read it.

The 'close' of a file is not close(fd) :)
But : the last close() so that underlying file refcount is 0

example 1)

fd = open("somefile", ...)
fd1 = dup(fd);
epoll_add_in_my_set(fd1);/* setup epoll work on fd1 */
{do_something;}
close(fd1); /* this is not the last close and will NOT close 'somefile' */
             /* It wont be removed from epoll sets NOW */


close(fd); /* oh yes, this one is the real 'file close', now we perform epoll 
cleanups */

epoll has to deal with files, but documentation is a User side documentation, 
so has to use 'file descriptors'. So everything that plays with the file 
descriptor table can make the thing complex to understand/document. 
(fork()/dup()/close()/exit()/exec()....)

example 2)

int pfd[2];
pipe(pfd);
epoll_add_in_my_set(pfd[0]);/* setup epoll work on pfd[0] for example */
pid = fork();
if (pid == 0) {


    close(pfd[0]); /* this is not the last close and will NOT close pipe */
	/* epoll has NO WAY to perform some cleanup at this stage */

    close(pfd[1]); /* this not the last close and will NOT close the pipe*/
    _exit(0);
    }
close(pfd[1]);
wait(NULL);
{do_something_epoll_related;}
close(pfd[0]); /* finally we close the pipe, and epoll can do its cleanup */

fork() is acting sort of dup() , as it increases all file refcounts.

You have problems about close()/dup()/fork()/... file descriptors semantic, 
which is handled by a layer independent from epoll stuff.



  reply	other threads:[~2007-10-27 10:24 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 [this message]
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=472311B8.5080408@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@tst.eu \
    --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).