[lkml]   [2002]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: thread groups bug?
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

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...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:20    [W:0.048 / U:4.572 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site