[Stackless] Re: [Python-Dev] Stackless pages
jeremy at alum.mit.edu
Mon Nov 6 19:48:45 CET 2000
>>>>> "SM" == Skip Montanaro <skip at mojam.com> writes:
Gordon> If we can't overcome "ew - a call might not ever return"
Gordon> there's not much sense in writing the PEPs.
SM> I disagree. The value in writing a stackless PEP is that those
SM> who would dismiss the idea out-of-hand or those who think they
SM> understand it but really don't might gain some insight into
SM> what's really going on.
I am probably in the "think I understand it but really don't" camp.
Since there have been few dissenting opinions so far, I assume I am
also the person to whom "ew - call might not ever return" should be
attributed. (I didn't think I said that, though.)
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 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.
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.
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).
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless