Re: thread groups bug?

[David Howells <dhowells@redhat.com>]

Benjamin LaHaise <bcrl@redhat.com> 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/<pid> 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