Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 13 Aug 2002 14:04:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 13 Aug 2002 14:04:50 -0400 Received: from mx2.elte.hu ([157.181.151.9]:30937 "HELO mx2.elte.hu") by vger.kernel.org with SMTP id ; Tue, 13 Aug 2002 14:04:21 -0400 Date: Tue, 13 Aug 2002 20:08:08 +0200 (CEST) From: Ingo Molnar Reply-To: Ingo Molnar To: Linus Torvalds Cc: linux-kernel@vger.kernel.org Subject: Re: [patch] exit_free(), 2.5.31-A0 In-Reply-To: Message-ID: 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: 1257 Lines: 29 On Tue, 13 Aug 2002, Linus Torvalds wrote: > If you want to do this, you can do it at _clone_ time, by extending on > the notion of "when I die, tell the parent using signal X" and making > that notion be a more generic "when I die, do X", where "X" migh include > updating some parent tables instead of sending a signal. > > But the magic "exit_write()" has to die. think about it - we have the *very same* problem in kernel-space, and we had it for years. People wanted to get rid of parent notification in helper processes for ages. A thread cannot free its own stack. We now can do it only with very special care and atomicity. The same thing cannot be done by user-space, because it has no 'atomic change and sys_exit()' operation at its hands. This capability is that the syscall provides - perhaps it should be called 'exit_atomic()' instead? (we got rid of all signal passing in the main fabric of pthreads - and that's done rightfully so. Futexes are used for message passing and eventing.) Ingo - 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/