Re: Torvalds on POSIX threads

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