[lkml]   [2001]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] 2.4.9 Make thread group id visible in/proc/<pid>/status

--On Monday, August 20, 2001 12:52:05 -0700 george anzinger
<> 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 T/L 678-3059

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 12:57    [W:0.052 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site