archive mirror
 help / color / mirror / Atom feed
From: Jamie Lokier <>
To: Davide Libenzi <>
Cc: Eric Varsanyi <>,
	Linux Kernel Mailing List <>
Subject: Re: epoll vs stdin/stdout
Date: Tue, 8 Jul 2003 01:52:26 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Davide Libenzi wrote:
> > Does this correctly free everything when you:
> >
> > 	declare interest in some events on fd 3
> > 	dup2(3,4)
> > 	close(3)
> > ?
> Neither the old and the new code does it. Cleanup is done either with an
> EPOLL_CTL_DEL (explicitly) or with the file* removal (__fput()). In you
> case when you close(4) if you do not do it explicitly.

The old code didn't need to do it, because the events were registered
for all the fd values pointing to a single file *.  That's cool -
that's exactly what anyone would expect.  The point of dup2() is that
the fds are equivalent, and share state (such as seek pointer).

Now you have two strange (IMHO unclean) behaviours, that an
application programmer needs to be aware of:

   1. Duplicate fds don't share registered event state.

Theoretically this could break an existing app, but I doubt if any
depend on this behaviour at present.  This is not likely to confuse anyone, as long as it is documented.

   2. When process A sends an fd to process B, the events will appear
      in process B _iff_ the fd number in B happens to be the same
      value as in process A.  (Without your patch, the events will always
      appear in process B).

      Furthermore, when process B dups the fd or passes it elsewhere,
      events will appear if the new fd happens to be the same as the
      original fd number in A.

      The only correct application code in this case is to use
      EPOLL_CTL_DEL in A and EPOLL_CTL_ADD in B, although it is
      confusing because you'll have programs which _sometimes_ work
      without that.

Oh, and:

   3. It's almost a memory leak.  Not quite because it's cleaned up
      eventually.  But it looks and feels just like one.

I guess what I'm saying is that hashing on fd number is quite simply
wrong.  The fundamental object is the file *, that's how its meant to be.

-- Jamie

  reply	other threads:[~2003-07-08  0:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-07 15:48 epoll vs stdin/stdout Eric Varsanyi
2003-07-07 18:57 ` Davide Libenzi
2003-07-07 19:47   ` Eric Varsanyi
2003-07-07 20:03     ` Jamie Lokier
2003-07-07 20:18       ` Miquel van Smoorenburg
2003-07-07 21:20         ` H. Peter Anvin
2003-07-07 22:11       ` Davide Libenzi
2003-07-08  0:24         ` Jamie Lokier
2003-07-08  0:23           ` Davide Libenzi
2003-07-07 22:12     ` Davide Libenzi
2003-07-07 23:26       ` Davide Libenzi
2003-07-08  0:32         ` Jamie Lokier
2003-07-08  0:32           ` Davide Libenzi
2003-07-08  0:52             ` Jamie Lokier [this message]
2003-07-08  1:13               ` Davide Libenzi
2003-07-08 12:34                 ` Jamie Lokier
2003-07-08 13:51                   ` Jamie Lokier
2003-07-08 15:20                     ` Davide Libenzi
2003-07-08 15:46         ` Eric Varsanyi
2003-07-08 15:42           ` Davide Libenzi
2003-07-08 16:02             ` Eric Varsanyi
2003-07-08 17:06               ` Davide Libenzi
2003-07-08 18:40                 ` Eric Varsanyi

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

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