Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 28 Feb 2002 11:30:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 28 Feb 2002 11:30:42 -0500 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237]:61678 "HELO executor.cambridge.redhat.com") by vger.kernel.org with SMTP id ; Thu, 28 Feb 2002 11:28:11 -0500 To: Benjamin LaHaise Cc: linux-kernel@vger.kernel.org, torvalds@transmeta.com Subject: Re: thread groups bug? In-Reply-To: Message from Benjamin LaHaise of "Thu, 28 Feb 2002 10:59:38 EST." <20020228105938.H8011@redhat.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 28 Feb 2002 16:28:09 +0000 Message-ID: <3135.1014913689@warthog.cambridge.redhat.com> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Benjamin LaHaise wrote: > > It seems that the TGID must also be a valid PID so that signal handling > > will work correctly... > > > > This could be solved by making PIDs independent of processes, but that's > > really not very nice. > > Oh, interesting. Note that we already allocate from the pid space for other > things, so it's entirely doable. But we still have to be able to send signals to the TGID. If there's a guaranteed PID of the same value, then that isn't a problem (except at the moment where multiple independent thread groups of the same TGID can be constructed). This could be done by making the PID independent of the process and giving it an ops table to direct signal handling and to control /proc/ dir lookup. BTW what other things are PIDs allocated for? I can see that PIDs won't be allocated if they are in use as PIDs, TGIDs and PGIDs. As far as I can see, get_pid() is only called by do_fork(). > Another choice would be to simply disallow the thread group leader from > exec'ing. Hmmm... Maybe... Return what error, though? > Linux threads traditionally try to remain as close to process behaviour as > possible, and allowing an individual thread to exec is very useful, so I'm > still in favour of allocating a new tgid. Yes, I agree that letting subsidary threads to escape the group is reasonable, but the master thread is definitely trickier:-/ As mentioned above, there'd be nothing backing the TGID, so kill() would have to search a list of thread groups too... David - 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/