Messages in this thread |  | | | Date | Mon, 20 Aug 2001 15:03:25 -0500 | | From | Dave McCracken <> | | Subject | Re: [PATCH] 2.4.9 Make thread group id visible in/proc/<pid>/status |
| |
--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 - 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/
|  |