[E-Lang] Why Not Coroutines? (was: Deadlock-free [was what is good about E?])

[Jonathan S. Shapiro]

> I believe most modern Unixes use separate stacks
> for signal handling.

Not so, and the whole push/pop thing isn't much of an impediment. Most
modern unixes provide a mechanism for using an alternative stack in order to
allow an application to ensure that signals are not subject to stack
overflow and also to provide an orderly mechanism for signal delivery in
multithreaded applications (which was a *real* can of worms). The default,
however, is that signals are delivered on the application stack unless the
application initiates some other protocol with the kernel.

The entire setup of the signal stack frame is performed by the kernel under
various locks, so the issue of push/pop atomicity is a bit of a red herring.
I know of no machine on which push/pop cannot readily be made atomic. The
critical operation is the stack pointer revision, and the correct ordering
is relatively easy to achieve. The simple rule is: don't write to a stack
area you have not allocated.

The tricky case is multiple threads using a common signal stack. This is an
unmitigated dissaster, and avoiding problems with it invariably requires
that (1) all signals be delivered to the same thread, or (2) each thread
provides its own signal stack.

Ironically, the POSIX standard failed to specify which thread should receive
an incoming signal. This has curious and unpleasant consequences for (e.g.)
SIGSEGV, as there is no guarantee in the standard that the offending thread
will be the one that receives the segmentation violation notice. In
practice, no UNIX implementation got this wrong for more than three "point"
releases... :-)

The whole POSIX threading model is buggered.


Jonathan