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

On Sat, Oct 27, 2007 at 12:23:52PM +0200, Eric Dumazet <dada1@cosmosbay.com> wrote:
> >    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 

epoll documentation easily can. there is nothig keeping it from it. don't
make silly arguments like that.

> Or should, since you had problems

You are again implying I lakc understanding. That is, however, not true.
I don't see the point in being insulted by you, so I won'T continue
talking to you :(

> The 'close' of a file is not close(fd) :)

Good that you understand that.

That is one of my problems, as the manpage talks about closing of the fd,
but there are multiple ways to do that, and some are not handled the same
way.

> epoll has to deal with files, but documentation is a User side 
> documentation, so has to use 'file descriptors'.

There is obviously no need for documentation to do that, contrary to your
claim. The manpages for e.g. dup or the official sus manpages manage to
document it (mostly) correctly, so your claim that documentation must use
file descriptors when the underlying file structure is meant is disproven.

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

No, I have no problem with dup at all.

I have a problem with explicitlx closing file descriptors in the child will
stop events for those files to be reported in the parent.

I am sorry, but I epxlained this very clearly a number of times, but for some
reason, apart from accusing me to not understanding files and file
descritpors or (clear enough) documentation, you ignore that and instead
hammer on other problems.

To me, it seems you are not the one who understands.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      pcg@goof.com
      -=====/_/_//_/\_,_/ /_/\_\

  reply	other threads:[~2007-10-27 10:46 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 [this message]
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=20071027104627.GA26748@schmorp.de \
    --to=schmorp@schmorp.de \
    --cc=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).