Re: [PATCH] 2.4.9 Make thread group id visible in/proc/<pid>/status

[Dave McCracken <dmccr@us.ibm.com>]

--On Monday, August 20, 2001 12:52:05 -0700 george anzinger 
<george@mvista.com> wrote:

> But this (signal_struct) does not share the signals, just the
> infrastructure.  I believe the thread standard defines some signals that
> are to be delivered to a "thread leader" regardless of what actually
> caused the signal.  Thus for these signals a separate mask & signal
> queue seems in order.  I suppose one could use the union of all the
> thread masks or some such, but this seems like a lot of overhead.  Also
> need to introduce the concept of a "thread leader" (the thread that this
> group of signals is to be delivered to) and what happens when the
> "thread leader" exits (how a new "thread leader" is chosen).  I suspect
> that the standard addresses all this, but I don't yet have access to the
> standard.

Oh, I agree that a need exists for this kind of semantic.  I was just 
saying that we do have a place to add the info necessary for it.  We could 
add it to signal_struct, or we could create another structure that's shared 
in a similar fashion.

We can easily add the concept of 'thread group leader'.  We already have 
the task that has 'tgid == pid', ie the first task that called clone() with 
CLONE_THREAD.  It would be simple enough to expand on that.

Actually the signal semantics you want in the kernel aren't necessarily 
just an implementation of the POSIX process-wide semantic.  What you want 
is to assume there's a library that's implementing the semantic, and funnel 
the signals to it.  Directing them all to a single task (thread group 
leader, for example) is one good way to do it.

Dave McCracken

======================================================================
Dave McCracken          IBM Linux Base Kernel Team      1-512-838-3059
dmccr@us.ibm.com                                        T/L   678-3059