Generators versus Coroutines

[Bryan Olson]

Michael wrote:
> Bryan Olson wrote:
> > Correct me if I'm wrong: Greenlets use a c-language extension to
> > do the routine switching; implementing the same in pure Python is
> > infeasable.
> 
> Correct. I never claimed that doing this in "pure" python was possible -
> largly because I think such a concept is pretty silly.
> 
> After all, what is "pure" anyway?
>    * Is using a module that comes with python allowed?

Most importantly: it means I can write in Python and run it with no
more than the standard Python distribution, on any of the many platforms
with reasonable support.


> IMO, the question is one of practicality. It is practical to use
> generators to build concurrent systems - and it works pretty well.

I've seen servers that rock written with explicit event handling,
threads, processes, and occasionally co-routines.  Where are the
great generator-based servers?


> > Generators rock, but they have a shadow of the power of co-routines.
> > Continuations are more powerful still.
> 
> And if you choose appropriate coding conventions every problem domain that
> co-routines and continuations can solve, generators can be used with
> almost equal effectiveness.
> 
> Having written large amounts of code using generators to gain parallelism
> in a single thread I don't say that lightly. I've found their simplicity
> useful for limiting the complexity of the architecture.

Have you been badly bitten by an evil co-routine?  They blow away 
generators on exactly the criteria you name.  Look at the specs of most
client-server protocols; they're defined in terms of the interaction of 
just the two parties.  With co-routines (or threads or processes), I
can implement a single line of control that handles just one client, then
support many clients just by changing the loop that accepts connections,
and adding yields within the I/O calls (plus maybe locking of the rare 
shared data).


-- 
--Bryan