Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264949AbTGHAh7 (ORCPT ); Mon, 7 Jul 2003 20:37:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264980AbTGHAh7 (ORCPT ); Mon, 7 Jul 2003 20:37:59 -0400 Received: from mail.jlokier.co.uk ([81.29.64.88]:55180 "EHLO mail.jlokier.co.uk") by vger.kernel.org with ESMTP id S264949AbTGHAh6 (ORCPT ); Mon, 7 Jul 2003 20:37:58 -0400 Date: Tue, 8 Jul 2003 01:52:26 +0100 From: Jamie Lokier To: Davide Libenzi Cc: Eric Varsanyi , Linux Kernel Mailing List Subject: Re: epoll vs stdin/stdout Message-ID: <20030708005226.GD12127@mail.jlokier.co.uk> References: <20030707154823.GA8696@srv.foo21.com> <20030707194736.GF9328@srv.foo21.com> <20030708003247.GB12127@mail.jlokier.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2136 Lines: 54 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 - 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/