linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Davide Libenzi <davidel@xmailserver.org>
To: Jamie Lokier <jamie@shareable.org>
Cc: Eric Varsanyi <e0216@foo21.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: epoll vs stdin/stdout
Date: Mon, 7 Jul 2003 18:13:33 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.55.0307071802360.3531@bigblue.dev.mcafeelabs.com> (raw)
In-Reply-To: <20030708005226.GD12127@mail.jlokier.co.uk>

On Tue, 8 Jul 2003, Jamie Lokier wrote:

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

That's no unclean. It is the purpose of the patch. You can do now :

	/* Remotely */
	dup2(3, 4);
	...
	evt.data.ptr = mydata0;
	evt.event = EPOLLIN | EPOLLET;
	epoll_ctl(epfd, EPOLL_CTL_ADD, 3, &evt);
	evt.data.ptr = mydata1;
	evt.event = EPOLLOUT | EPOLLET;
	epoll_ctl(epfd, EPOLL_CTL_ADD, 4, &evt);

And receive two different events for "mydata0" and "mydata1". That's what
you really link to.



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

This is false. Internally it's the file* that is the sink for events. So
they will receive events as long as the originator file* is alive.



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

This is false too. When the last user (file count) of the underneath file*
will drop it, it will be cleaned. This is not a memory leak in books where
I studied. Is like saying that :

int main() {
	int i;
	for (i = 0; i < 1000; i++)
		open(...);
	for (;;)
		sleep(1);
	return 0;
}

is a memory leak ;)



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

The architecture is all based on the file*, it is there that events shows
up. The (file*, fd) key is a constraint.



- Davide


  reply	other threads:[~2003-07-08  1:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-07 15:48 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
2003-07-08  1:13               ` Davide Libenzi [this message]
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:
  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=Pine.LNX.4.55.0307071802360.3531@bigblue.dev.mcafeelabs.com \
    --to=davidel@xmailserver.org \
    --cc=e0216@foo21.com \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: epoll vs stdin/stdout' \
    /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).