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

[Dan Moniz]

At 11:03 PM -0700 7/18/01, Richard wrote:

[snip]

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

Part of the confusion is due to some lack of explaining on my part. 
My general advocacy tack has two facets:

1) I think coroutines are dismissed too often in general programming, 
especially where people resort to implementing complicated state 
machines for seemingly simple tasks. Coroutines usually solve these 
issues in a cleaner, more direct fashion. I'm all for coroutines in a 
language, but I don't think E has them, nor do I think putting them 
into E would be non-trivial and realize a lot of additional benefit 
such that it would be worth it. I'm unsure as to those issues, 
they're MarkM's domain.

2) Coroutine threads are amenable (again, in certain cases) over 
large thread implementations, like pthreads, even without the 
OS-level integration because they can handle many tasks you would 
otherwise be using threads for much more efficiently and with less 
programmer pain. They don't do everything threads do, since they are 
user space, but they do well considering (i.e.: virtual memory 
consumption).

Coroutine threads (or user threads) are merely one application 
(albeit a popular one) of coroutines.


-- 
Dan Moniz <dnm@pobox.com> [http://www.pobox.com/~dnm/]