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@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