[Python-Dev] Stackless Python - Pros and Cons

Christian Tismer tismer@appliedbiometrics.com
Mon, 07 Aug 2000 15:47:39 +0200


[about recursion and continuations]

>   CT> Right. What you see here is the incompleteness of Stackless.  In
>   CT> order to get this "right", I would have to change many parts of
>   CT> the implementation, in order to allow for continuations in every
>   CT> (probably even unwanted) place.  I could not do this.
> 
>   CT> Instead, the situation of these still occouring recursions are
>   CT> handled differently. continuationmodule guarantees, that in the
>   CT> context of recursive interpreter calls, the given stack order of
>   CT> execution is obeyed. Violations of this cause simply an
>   CT> exception.
> 
> Let me make sure I understand: If I invoke a continuation when there
> are extra C stack frames between the mainloop invocation that captured
> the continuation and the call of the continuation, the interpreter
> raises an exception?

Not always. Frames which are not currently bound by an
interpreter acting on them can always be jump targets.
Only those frames which are currently in the middle of
an opcode are forbidden.

> If so, continuations don't sound like they would mix well with C
> extension modules and callbacks.  I guess it also could not be used
> inside methods that implement operator overloading.  Is there a simple
> set of rules that describe the situtations where they will not work?

Right. In order to have good mixing with C callbacks, extra
work is necessary. The C extension module must then play the
same frame dribbling game as the eval_loop does. An example
can be found in stackless map.
If the C extension does not do so, it restricts execution
order in the way I explained. This is not always needed,
and it is no new requirement for C developers to do so.
Only if they want to support free continuation switching,
they have to implement it.

The simple set of rules where continuations will not work at
the moment is: Generally it does not work across interpreter
recursions. At least restrictions appear:

- you cannot run an import and jump off to the caller's frame
+ but you can save a continuation in your import and use it
  later, when this recursive interpreter is gone.

- all special class functions are restricted.
+ but you can for instance save a continuation in __init__
  and use it later, when the init recursion has gone.

Reducing all these restrictions is a major task, and there
are situations where it looks impossible without an extra
subinterpreter language. If you look into the implementation
of operators like __add__, you will see that there are
repeated method calls which all may cause other interpreters
to show up. I tried to find a way to roll these functions
out in a restartable way, but it is quite a mess. The
clean way to do it would be to have microcodes, and to allow
for continuations to be caught between them.

this-is-a-stackless-3000-feature - ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com