Because of my stupidity Linus' reply didn't make it to linux-kernel.
Here it is for those who're interested:
------- Start of forwarded message -------
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Date: Sat, 2 Sep 2000 11:56:05 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
cc: drepper@redhat.com, linux-kernel@kernel.org
Subject: Re: thread group comments
In-Reply-To: <200009021158.e82Bwh900891@delius.kettenis.local>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 2 Sep 2000, Mark Kettenis wrote:
> >
> > * Send a thread-group-wide signal.
> > *
> > * Rule: SIGSTOP and SIGKILL get delivered to _everybody_.
> >
> > That's OK. Except that is a signal whose default action is to
> > terminate the process is not caught be the application, this signal is
> > also handled process-wide. E.g., if there is no SIGSEGV handler the
> > whole process is terminated.
>
> Fair enough.
>
> Looking through the code in test8-pre1, I think there are more
> problems with (non-fatal) signals:
>
> * sys_rt_sigqueueinfo() calls kill_proc_info() (to avoid the
> "signal-to-pgid" semantics), but I think it should be calling
> kill_tg_info().
Indeed. It makes sense to have rt_sigqueue() use the same logic as a
normal kill(). I just overlooked it entirely.
> * SIGCONT isn't handled correctly:
>
> "[W]hen SIGCONT is generated for a process all pending stop signals
> for that process shall be discarded."
A lot of these issues should be fixed in test8-pre2. It does more of a
true job of having shared signals instead of emulating them with a global
"blocked" list and spreading them out to be local signals.
(The "spread out the global signals" approach in test8-pre1 ends up being
fundamentally broken: it has various interesting problems with threads
dying or starting to block signals that they used to not block, and then
we should really give the signal we made local back to the global pool
etc. Nasty.).
> * The interaction between thread-groups and process-groups seems to be
> wrong:
>
> Right now when a signal is sent to a process-group, it will be sent
> to all tasks in the process-group. I think however, that the signal
> should be "sent" only to thread-group leaders in the process-group
> and distributed to the threads according to the rules set by
> kill_tg_info().
Possibly. The problem here is that it makes for very nasty locking.
Right now the thread groups are only known by synchronous threads: other
processes sending you a signal, or you yourself looking at your signals.
That means that they can use regular spinlocks to protect the shared
state.
In contrast, if you start doing the thread group semantics for
asynchronous things like ^C etc, we'd need to change that to
interrupt-safe spinlocks which are much more expensive and have other
nasty properties.
We'll see. I'd like to have people check out the shared semantics, and see
if it works reasonably well for pthreads, and we'll take care of remaining
details after the concept has been proven.
The shared signals stuff actually ended up being fairly trivial: the most
work by far was the splitting up of functions to simplify the code and
allow re-use of the same stuff for the thread group logic and the single
thread logic. I think most of it is clearer now anyway, but there are some
locking issues still that need to be clarified.
Linus
------- End of forwarded message -------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:14 EST