There are already rules for what happens when you send a signal
to a process that includes more than on thread, and they allow the author
of the threaded program to control which threads handle which errors.
The short version of how it should be, IMO:
1) Synchronous signals like SIGFPE and SIGSEGV go to the thread
that caused them. If sent to the process, they are ignored if the last
'signal' command said to ignore them. Otherwise they go to a signal
handler (if one's installed). Otherwise they terminate all threads.
2) Asynchronous fatal signals (SIGTERM, SIGKILL) terminate the
group of threads unless it's a blockable signal (not KILL or STOP) and is
blocked. If a thread installed a signal handler and the signal is not
unblockable, the handler is called by the thread that installed it.
DS
On Wed, 31 Jul 1996, Lex Spoon wrote:
> Allowing threads to share pid's means we have to go through and rethink
> what a lot of things mean. Do kill() and waitpid() operate on just
> one thread or all of them? People are going to sometimes want each
> of these cases, so we have to expand kill() and waitpid() to deal
> with it.
>
> Unix already has a way of dealing with a group of cooperating processes:
> process groups. Why not just use this concept for threads, too? If you
> want to kill all the threads in certain process group 37, you do
> kill(-37, SIGWHATEVER).
>
> I CAN see possible uses for wanting to address a "group of threads
> sharing the same memory mappings". But most often, aren't processes and
> process groups just what most people want?