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

[Richard]

Dan Moniz writes:

>Comp Sci. students and Kunth fans can feel free to skip over the rest 
>of this mail, since it's really just advocacy of coroutines, the 
>underdog of concurrent control structures.

>Coroutines in C by Simon Tatham, 
><http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html>, an 
>application of Knuth's theory resulting in a stack-based mimic in C 
>(Knuth wrote coroutines in assembly, C makes Kunth's coroutines 
>impractical due to it's structure) applied to a C code problem. In 
>related C hackery, Tom Duff's discussion of his Duff's Device has 
>some related coroutine hints 
><http://www.lysator.liu.se/c/duffs-device.html>

Those 2 web pages describe coroutines, but Mark is talking about
coroutine *threads* aka user or cooperative threads.
Different things.  Eg, unless I'm really missing something, one cannot
have one coroutine blocked on I/O while another coroutine is busy.

In reply to Dan, Mark S. Miller writes:

>One of E's ancestors, Tclio/Webmart http://www.agorics.com/webmart.html 
>http://www.sun.com/960201/cover/webmart.html was based coroutine scheduling. 

I think what Dan means is that he has seen code where one thread
just produces a stream of values and another thread consumes said values.
He would prefer for coroutines to be used for that instead of
threads, if the language supports coroutines, and I think I share his
preference.

here's a definition of coroutine threads:

   User threads are also known as coroutine threads or cooperative
   threads. The kernel does not know about them -- application code
   (usually in a library) does the context switching. Context switching
   between user threads is faster, since the thread management in
   user-space is simpler: no user-to-kernel context switch needs to be
   done. Coroutine threads are typically non-preemptive: a thread must
   voluntarily give up the CPU to another thread by explicitly calling a
   yield function. Furthermore, if a program using coroutine threads is
   run on a multiprocessor, very little speedup will occur: the OS can
   not make the coroutine threads run simultaneously on two or more
   processors.

In reply to Mark, Bill Frantz writes:

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

Bill is talking about coroutines.

Were KeyKOS apps primarily written in assembler, Bill?