Torvalds on POSIX threads

I agree. POSIX threads' signal-handling model is really awkward, if I
understand it correctly. I've never spent a lot of time on it, but
wearing my implementor hat, just the very idea of having a separate
signal mask for each thread gives me the screaming heebie jeebies.

I suspect that Topaz's threading will be built on our own
abstractions, possibly borrowed from the Mozilla code (as Linus
himself suggested). But that's a ways down the pike.

Signals are pretty broken under threads, that's for sure. Their limitations
really come to the forefront with threads. The lack of guarantees built
into the standard doesn't help much either.

The only sane way to handle signals with threads is to mask them off for
all your threads except one that's set up to handle them. (The various OS
vendors don't even agree on which signals are synchronous and which are
async under threads just to add to the fun)

Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk

Somewhat tangential but still related:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-04/msg00418.html

That's just one half of the problem. We still need a first-class event
abstraction. Can anyone kindly summarize the status of the event-loop
module(s) for me? Thanks in advance.


Sarathy
gsar@ActiveState.com

CS> I agree. POSIX threads' signal-handling model is really awkward, if I
CS> understand it correctly. I've never spent a lot of time on it, but
CS> wearing my implementor hat, just the very idea of having a separate
CS> signal mask for each thread gives me the screaming heebie jeebies.

<stupid question>

Why should a signal mask per_THREAD, be any harder than a signal mask
per_PROCESS?

</stupid question>

I recall having this under good ol' MVS. Each process/task within each
address space had it's own set of capablities.

Hmm, unless the problem is the poor split between address spaces and
processes/tasks under unix?

<chaim>

<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>

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.
<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.

It's a technical compromise and isn't perfect. This is supposed to be a
surprise? There's not a cross-platform standard out there that doesn't suck
in one form or fashion. The Linux implementation does exacerbate the
problems, though it wouldn't surprise me if that was intentional.

It'd be nice if they took the damn POSIX Pthreads label off the things--if
they aren't abiding by the standard they shouldn't use the name.

Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk