I hoped somebody else would write something about Linus' test8-pre1
thread group changes but I haven't seen anything. Now you have to
bear with me even though I'm incompetent[1].
I took a look at the code and thought about the changes
necessary/possible in the thread library. Here's what I came up with
so far:
1st Problem: One signal handler process process-wide
What is handled correctly now is sending signals to the group. Also
that every thread has its mask. But there must be exactly one signal
handler installed. I.e., a sigaction() call to set a new handler has
consequences process-wide. Since this muse be atomic I think the
information should be kept in the thread group leader's data
structures and the other threads should simply use this information
all the time. Yeah, I know, one more indirection.
2nd Problem: Fatal signal handling
kernel/signal.c contains:
* 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.
This will have to go hand in hand with an extension of the core file
format to include information about all threads but for the time being
it's enough if only the offending thread is dumped and the rest simply
killed.
3rd Problem: one uid/gid process-wide
All the ID (uid/guid/euid/egid/...) must be process wide. The problem
is similar to the signal handler. I think one should again keep the
information exclusively in the master thread and have all others refer
to this information.
4th Problem: thread termination
In general, thread termination is not of much interest for the rest of
the system. It is in the moment but if the fatal signal handling is
done this will change.
If a thread gets a fatal signal, the whole process is killed. No
cleanup necessary. Signal handlers can be installed if necessary.
If a thread terminates naturally and can perform the cleanup itself.
In any case, the death signal should be ignored. Except for the last
thread, of course, which has to notify the process starting the MT
application.
I can see two possible solutions, neither of which I've tried:
- the termination signal given to clone calls is 0 (zero). So no
notification is sent out. Question is: does the kernel allow this?
- the kernel ignores the SIGCHLD signal for all threads except the last
one
In any case is there the problem how to handle the termination of the
master thread. If it is not aware of starting and terminating threads
I could imagine some user-level mechanisms to make this work but they
are not very clean (it involves changing the death signal in the
thread depending on the situation). If there is something people
think the kernel could do this would be probably better.
5th Problem: suspended starting
Related to the last problem a good old friend pops up. Depending on
the solution of the last problem it might be necessary to add
suspended starting of threads. The problem is that sometimes the
starter has to modify parameters (e.g., scheduler) of the newly
started thread before it can actually start working. If this fails,
the new thread must be terminated immediately. But who will get the
termination signal? The data structures for the new thread must be
removed as well and this after the new thread is guaranteed to be
vanished.
Anyway, I still think it's not even worth discussing this much since
the whole change to implement this is only a few lines. And it's in
no fastpath.
I might have more if I get deeper into implementation details. But if
the above problems could be fixed we'd be a long way down the read to
a good implementation.
[1] Since Linus says so it must be true.
-- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ - 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 : Fri Sep 01 2000 - 17:54:17 EDT