[Stackless] Re: [Python-Dev] Stackless pages

Gordon McMillan gmcm at hypernet.com
Mon Nov 6 21:36:42 CET 2000

Jeremy wrote:

> I should clarify exactly what I am worried about with C API calls.  I
> don't care if they never return, which is already possible since it
> could invoke some Python code that goes into an infinite loop.  I am
> worried about a C API call that itself never returns even though one
> of its parents does.  

I don't see how that's possible, but maybe I'm not thinking 
perversely enough. Maybe one could pass a continuation 
object through the C code, and the Python called by the C 
code could try to use it? I do know that Christian keeps track 
of recursive executions of eval_code and blocks off a bunch of 
stuff if you're in a nested level. This is less than ideal in a 
theoretical sense, but probably not all *that* big a deal in 

> I am worried, as Christian explained, about a C
> API call that receives the "unwind token" when it isn't expecting it.
> I do not understand how we keep Python's simple, clean C API and also
> support continuations.  I have been waiting for the PEP because I hope
> it will explain this issue.

If you *want* unwind tokens, you use a different API to call 
back into Python. You won't get one if you use the normal API.
>   SM> I can't help but think, "wow, microthreads sound like they're
>   SM> very efficient and offer a real chance of providing portable
>   SM> threading for Python".  The route to mainstream acceptance of
>   SM> stackless and realization of this thought will be through a PEP.
>   SM> I wouldn't give up at this point.
> Indeed, fast and efficient user-level threads seem like a fine idea.
> I do not understand, again, how stackless + continuations is required
> to implement them.  Just recently wrote: "Continuations aren't even
> needed to do full coroutining and uthreading."  Is even stackless
> required?  I hope the PEP will explain this requirement.

The major expense of a real thread is in allocating a big-
enough-for-anything stack. Microthreads work because, frame 
by frame, they can allocate just enough to get thru the frame. 
Stackless may not be a requirement, but something very like 
it sure seems to be.
> While we're going for a full disclosure of things I don't understand
> :-), I hope someone will explain why the continuation interface is so
> much more complicated than call/cc.  If Python were to adopt a
> continuation interface, it would seem desirable to use the same
> interface as Scheme and ML, two languages with long experience using
> continuations (mostly to implement threads and exceptions).

First of all, it probably doesn't need to be so complicated. But 
Christian exposed a bunch of possibly useful primitives, and 
no consensus has emerged as to which ones are useful and 
which aren't. That's why I wrote example3 6 times. No two 
people seem to have the same favorite patterns. I find that 
some rather subtle factors (is it a source? a sink? both? who's 
in charge of its lifetime?) make some patterns work better 
than others. We have made some progress on a much simpler 
API for doing coroutines, but I haven't even tried example3 in it 

As for the second question: Python is not a functional 
language. That makes a huge difference.

- Gordon
Stackless mailing list
Stackless at starship.python.net

More information about the Stackless mailing list