[Stackless] Re: [Python-Dev] Stackless pages
Just van Rossum
just at letterror.com
Mon Nov 6 20:30:30 CET 2000
At 1:48 PM -0500 06-11-2000, Jeremy Hylton wrote:
> 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 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.
That's not possible. All existing Python API calls will behave _exactly_
the same in Stackless Python as they do now.
>I am worried, as Christian explained, about a C
>API call that receives the "unwind token" when it isn't expecting it.
Again, not to worry: Stackless won't throw the unwind token at you if you
stick to the existing API. The only calls that can return the unwind token
are those suffixed with _nr (as in non-recursive). I've actually been
advocating to Chris to drop the unwind token at all, and simply give those
*_nr calls an additional (return) argument, like so:
Py_SomeFunction_nr(...., &unwind). This has two advantages over the current
- it's cleaner
- you can now return a value _and_ unwind the stack
(the latter is also possible now, but the "return value" is then
transported through a special field in the frame object. Hmhm.)
The disadvantage (according to Chris) is that it requires more
modifications to the existing Python code base, as the unwind token can
pass through existing code. I'm not sure I buy this. First it doesn't seem
all that much code that takes advantage of this, and secondly I would feel
uncomfortable letting the unwind token pass through code that's not aware
of its existence.
>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.
Of course stackless is needed for co-routining and uthreading: they both do
context switching, which would involve C stack copying in Python weren't
>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).
I couldn't agree more with you! The argument against call/cc in Python --
which I would call apply_cc() instead -- is that it would be less useful in
Python because scopes don't nest. I don't agree with that, as it's simple
to have apply_cc() take additional arguments. Oh, and now that you're
tackling the nested scopes issue, the argument may get even weaker...
There's one IMHO major problem with Chris' continuation API: continuations
aren't immutable, in the sense that they can point to a different places
within an execution frame at different times, due to the co.update()
method. It muddles the semantics, as it forces users to think in terms of
_frames_ in order to understand what's going on. Continuations are the
abstraction, frames are the implementation. Mixing the two only makes it
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless