Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265946AbTGHBGn (ORCPT ); Mon, 7 Jul 2003 21:06:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265948AbTGHBGn (ORCPT ); Mon, 7 Jul 2003 21:06:43 -0400 Received: from x35.xmailserver.org ([208.129.208.51]:11136 "EHLO x35.xmailserver.org") by vger.kernel.org with ESMTP id S265946AbTGHBGk (ORCPT ); Mon, 7 Jul 2003 21:06:40 -0400 X-AuthUser: davidel@xmailserver.org Date: Mon, 7 Jul 2003 18:13:33 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@bigblue.dev.mcafeelabs.com To: Jamie Lokier cc: Eric Varsanyi , Linux Kernel Mailing List Subject: Re: epoll vs stdin/stdout In-Reply-To: <20030708005226.GD12127@mail.jlokier.co.uk> Message-ID: References: <20030707154823.GA8696@srv.foo21.com> <20030707194736.GF9328@srv.foo21.com> <20030708003247.GB12127@mail.jlokier.co.uk> <20030708005226.GD12127@mail.jlokier.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2653 Lines: 85 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/