[Stackless] Questions on the Evolution of Stackless

Andrew Francis andrewfr_ice at yahoo.com
Tue Feb 26 22:13:05 CET 2008

Hello Christopher et al:

--- Christopher Armstrong <radix at twistedmatrix.com>

> Generators are not coroutines and cannot be used to
> implement coroutines. Unfortunately the Python
>community (starting with the PEP for generators in
>2.5) has decided to use the word "coroutine" to
> describe what they can do, so probably it's
> impossible to get away from that misnomer at this

Yes, I have reading stuff like PEP 342 and reading
blog posts like "Knowing Santa Claus is Fake Doesn't
Ruin Christmas."

> The main difference is that you cannot switch
> between arbitrary generators at arbitrary stack
>levels. This means that every frame in the stack has
>to have knowledge of potential context
> switches. inlineCallbacks is an example of this;
>every frame in the stack needs to know to 'yield' the
>deferred in order to wait for its result.

Perhaps the David Mertz papers have given me an
inflated sense of what generators can do ... :-)

Thanks for the explanation. I think I follow. I recall
some code for unwinding the generator in
deferred._inlineCallBacks checking if an object was a
deferred and guarding against stuff like unbounded
recursion. I don't know enough to exactly follow what
is happening. 

[about real co-routines]
>This means it's easier for bad stuff to happen, but
>it's also more flexible.

Yes, co-routines are no magic amulet against
traditional concurrency problems. As I will argue in
my paper, I believe what the Stackless  brings to the
table is a form of "clutterless" (to use a term from
the paper "Experimental Prototyping in Smalltalk" for
describing "Fearless Programming") concurrent
programming. Still you can experience deadlock and
race/data corruption problems.

Once again, thanks for the explanation (and I think
inlineCallbacks are cool).


Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

More information about the Stackless mailing list