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

[Bill Frantz]

At 1:36 PM -0700 7/18/01, Mark S. Miller wrote:
>At 04:45 PM Tuesday 7/17/01, Dan Moniz wrote:
>>So, in as much as my motive is to inform, I'd like to have more people
>>consider coroutines. I'm not sure if they make sense for E (I would
>>initially tend to doubt it, since Java already provides threads, but seeing
>>as how this discussion arose out of possible changes to Java thread support,
>>I suppose it's germane), but they do make sense in many other places where
>>threads just seem to be too much bother than their worth.

A bit off topic for this list, but I can't resist noting that KeyKOS
provides coroutines.  A "call" operation on a "resume key" is a coroutine.
(A resume key is produced by a call operation to allow the callee to return
to the caller.  Calling a resume key consumes the resume key and produces a
new resume key.)

>2) From one instruction/expression/statement to the next, assume that the
>immediately accessible world is only affected in the ways I (this code)
>affects it.

You really have to consider the concurrency protections provided by the
hardware platform at the instruction level to do a complete analysis.  Just
looking at the high level statement/expression is not enough because most
hardware allows values to change between the instructions implementing the
statement/expression.  (Some hardware permits data to change during the
execution of a single instruction.  The IBM 370 for example.)  The analysis
may also depend on whether the compiler saves values in registers during a
statement/expression or re-fetches them from memory each time they are used
(volatile attribute).

Consider the Unix signal facility.  On the DEC hardware, where Unix had its
first home, stack pushes were atomic.  Because they were atomic, a signal
handler could share the stack with the main program.

On machines like the IBM 370 and most RISCs, changing the stack pointer,
and storing/fetching from the stack must be very carefully ordered in order
to use the same stack.  I believe most modern Unixes use separate stacks
for signal handling.

Executive overview: It's a scary can of worms.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz@pwpconsult.com | fair use.              | Los Gatos, CA 95032, USA