[Python-Dev] uthread strawman

Bill Tutt billtut at microsoft.com
Fri Nov 10 20:49:40 CET 2000


From: 	Christian Tismer [mailto:tismer at tismer.com] 

> Bill Tutt wrote:
> > 
> > Guido van Rossum [mailto:guido at python.org] wrote:
> > > > Christian Tismer wrote:
> > > > > Does anybody know of a useful example where continuations
> > > > are really needed?
> > > [Bill Tutt]

> Bill on [server architecture, async state machine]

> > > Indeed, this kind of server architecture is typically done with
> > > coroutines -- it's not a good argument for the full power of
> > > continuations. :-)
> 
> > Hrm, but can I get enough info from the coroutine support to
> > automatically determine which "work item queue" the paused routine
> > should go into after the "blocking" operation completes?
> > Additionally, the coroutine can't be stuck to only one system
> > thread. That would be bad.

> Coroutine vs. continuation isn't the point here, I think.
> What you would likely need is gathering information about
> the frames and variables in your co-whatever. This is quite
> simple to implement, with either architecture.
> My next version will not only allow to inspect the eval
> stack of a frame, but also inspection and modification
> of local variables; still this is no continuation feature.
> We can simply inspect anything.

Coolness. 

> What makes the difference is callability:
> Whenever we expose arbitrary frames as callable objects,
> or we provide an unrestricted other way to execute them,
> then exactly all the problems and consequences of
> continuations pop up: we need to clone execution state,
> since now it is possible to have more than one state for
> a frame.
> If we avoid this, we can still have all control and debugging
> features with coroutines.

Ah, well this definitely would cause all sorts of confusing things.
I did mention I hadn't spent much time thinking about all of the
implementation details, I just know the requirements the architecture idea
has. :) As long as the co-whatevers can migrate to any system thread, I'm
one happy camper.

Thanks for helping clear stuff up folks,
Bill



More information about the Stackless mailing list