[Python-Dev] 'stackless' python?

Christian Tismer tismer at appliedbiometrics.com
Wed May 19 21:30:18 CEST 1999


Tim Peters wrote:
...
> [Christian]
> > Actually, the frame-copying was not enough to make this
> > all behave correctly. Since I didn't change the interpreter,
> > the ceval.c incarnations still had copies to the old frames.
> > The only effect which I achieved with frame copying was
> > that the refcounts were increased correctly.
> 
> All right!  Now you're closer to the real solution <wink>; i.e., copying
> wasn't really needed here, but keeping stuff alive was.  In Scheme terms,
> when we entered main originally a set of bindings was created for its
> locals, and it is that very same set of bindings to which the continuation
> returns.  So the continuation *should* reuse them -- making a copy of the
> locals is semantically hosed.

I tried the most simple thing, and this seemed to be duplicating
the current state of the machine. The frame holds the stack,
and references to all objects.
By chance, the locals are not in a dict, but unpacked into
the frame. (Sometimes I agree with Guido, that optimization
is considered harmful :-)

> This is clearer in Scheme because its "stack" holds *only* control-flow info
> (bindings follow a chain of static links, independent of the current "call
> stack"), so there's no temptation to run off copying bindings too.

The Python stack, besides its intermingledness with the machine
stack, is basically its chain of frames. The value stack pointer
still hides in the machine stack, but that's easy to change.
So the real Scheme-like part is this chain, methinks, with
the current bytecode offset and value stack info.

Making a copy of this in a restartable way means to increase
the refcount of all objects in a frame. Would it be correct
to undo the effect of fast locals before splitting, and redoing
it on activation?

Or do I need to rethink the whole structure? What should
be natural for Python, it at all?

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