[Stackless] Re: [Python-Dev] Stackless pages
gmcm at hypernet.com
Mon Nov 6 21:36:42 CET 2000
> 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.
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless