According to Chaim Frenkel:
> <stupid question>
> Why should a signal mask per_THREAD, be any harder than a signal mask
> per_PROCESS?
> </stupid question>
Because POSIX threads are _supposed_ to be implementable on top of a
UNIX system that doesn't have kernel threads. And that means that a
robust implementation has do do a lot of user-mode processing on each
signal delivery, *or* has to make at least one and maybe more system
calls on every user-mode-thread context switch.
On a system like Linux with kernel threads, that part isn't _so_ bad.
But there's still an unholy mess surrounding the semantics of signal
delivery; a group of threads is in some ways a bunch of separate
processes, but in some ways is still supposed to act like one process.
Linux's clean separation of process semantics into flags for the
clone() call is really a great step toward sanity.
> I recall having this under good ol' MVS. Each process/task within
> each address space had it's own set of capablities.
That, in itself, is no big deal.
> <old professor>
> Now there was some raw threading. None of this posix mush. Lock and Set,
> Spin Locks, bare metal. Oh, those were the days....
> </old professor>
<old hacker>
Lock and set? Luxury! When I started with threading, we had to flush
the cache manually with a dummy jump...
</old hacker>
PS: Whether this is true or not is left as an exercise for the reader.
--
Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
