Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 20 Aug 2002 06:55:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 20 Aug 2002 06:55:32 -0400 Received: from faui02.informatik.uni-erlangen.de ([131.188.30.102]:11963 "EHLO faui02.informatik.uni-erlangen.de") by vger.kernel.org with ESMTP id ; Tue, 20 Aug 2002 06:55:32 -0400 Date: Tue, 20 Aug 2002 12:36:37 +0200 From: Richard Zidlicky To: Ingo Molnar Cc: Linus Torvalds , linux-kernel@vger.kernel.org Subject: Re: [patch] O(1) sys_exit(), threading, scalable-exit-2.5.31-A6 Message-ID: <20020820123637.A800@linux-m68k.org> References:

Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mingo@elte.hu on Mon, Aug 19, 2002 at 08:08:10PM +0200 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1443 Lines: 29 On Mon, Aug 19, 2002 at 08:08:10PM +0200, Ingo Molnar wrote: > > On Mon, 19 Aug 2002, Linus Torvalds wrote: > > > I'd be happy to apply this patch (well, your fixed version), but I think > > I'd prefer even more to make the whole reparenting go away, and keep the > > child list valid all through the lifetime of a process. How painful > > could that be? > > the problem is that the tracing task wants to do a wait4() on all traced > children, and the only way to get that is to have the traced tasks in the > child list. Eg. strace -f traces a random number of tasks, and after the > PTRACE_CONTINUE call, the wait4 done by strace must be able to 'get > events' from pretty much any of the traced tasks. So unless the ptrace > interface is reworked in an incompatible way, i cannot see how this would > work. wait4 could perhaps somehow search the whole tasklist, but that > could be a pretty big pain even for something like strace. the whole signal driven approach of ptrace is imho not very elegant and causes high overhead. So reworking the ptrace interface to avoid signals would be a good idea. Instead of wait4 the tracer could eg block or poll on read of /proc/#num/ptrace. Richard - 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/