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

Just van Rossum just at letterror.com
Mon Nov 6 20:04:25 CET 2000

>> What I didn't quite understand was that these (new) objections seem to be
>> about the C API: Stackless doesn't play _any_ C tricks, so I was under the
>> impression all C calls are garuanteed to return, no? On the Python level:
>> who cares, that's what continuations are for...

>Shure, the C calls do return.
>What Gordon means is (I think): If a C function calls a Python
>function, it assumes that the Python function has run. With
>Stackless, this is no longer true. This is indicated by not
>returning the function result, but the Py_UnwindToken, indicating
>that the call to the Python function has been deferred.
>However this may be implemented in the future, the principle
>must stay: We need tail-recursive calls. That means to delay
>the execution of a Python function, return from the calling C
>function, then execute the Python function via the scheduler,
>and then re-entering the C function.

Erm, I'm not sure if that was what Jeremy was alluding to. I interpreted it
as "what happens if you capture a continuation in an actual recursive
interpreter call". The existing Python API is guaranteed not to return
Py_UnwindToken after all, so it _must_ recurse. But as you've shown with
the current stackless implementation, this is a problem which can be
overcome. Full stacklessness may not be doable now, but you've also shown
convincingly that that's not a show stopper. Oh well.


Stackless mailing list
Stackless at starship.python.net

More information about the Stackless mailing list