[Python-Dev] 'stackless' python?

Christian Tismer tismer at appliedbiometrics.com
Sun May 16 20:31:01 CEST 1999


Christian Tismer wrote:
> 
> rushing at nightmare.com wrote:
[...]

> > I haven't tested it thoroughly, but I have successfully saved and
> > invoked (and reinvoked) a continuation.  Caveat: I have to turn off
> > Py_DECREF in order to keep it from crashing.

It is possible, but a little hard.
To take a working snapshot of the current thread's
stack, one needs not only the stack snapshot which 
continue.c provides, but also a restorable copy of
all frame objects involved so far.
A copy of the current frame chain must be built, with
proper reference counting of all involved elements.
And this is the crux: The current stack pointer of the
VM is not present in the frame objects, but hangs
around somewhere on the machine stack.
Two solutions:

1) modify PyFrameObject by adding a field which holds
   the stack pointer, when a function is called. 
   I don't like to change the VM in any way for this.
2) use the lasti field which holds the last VM instruction
   offset. Then scan the opcodes of the code object
   and calculate the current stack level. This is possible
   since Guido's code generator creates code with the stack
   level lexically bound to the code offset.

Now we can incref all the referenced objects in the frame.
This must be done for the whole chain, which is copied and
relinked during that. This chain is then held as a
property of the continuation object.

To throw the continuation, the current frame chain must
be cleared, and the saved one is inserted, together with
the machine stack operation which Sam has already.

A little hefty, isn't it?

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home




More information about the Python-Dev mailing list