Jeremy Hylton wrote: [TP+CT about frame copies et al]
Wouldn't it be easier to increase the refcount on the frame object? Then you wouldn't need to worry about the recounts on all the objects in the frame, because they would only be decrefed when the frame is deallocated.
Well, the frame is supposed to be run twice, since there are two incarnations of interpreters working on it: The original one, and later, when it is thown, another one (or the same, but, in principle). The frame could have been in any state, with a couple of objects on the stack. My splitting function can be invoked in some nested context, so I have a current opcode position, and a current stack position. Running this once leaves the stack empty, since all the objects are decrefed. Running this a second time gives a GPF, since the stack is empty. Therefore, I made a copy which means to create a duplicate frame with an extra refcound for all the objects. This makes sure that both can be restarted at any time.
It seems like the two other things you would need are some way to get a copy of the current frame and a means to invoke eval_code2 with an already existing stack frame instead of a new one.
Well, that's exactly where I'm working on.
(This sounds too simple, so it's obviously wrong. I'm just not sure where. Is the problem that you really need a seperate stack/graph to hold the frames? If we leave them on the Python stack, it could be hard to dis-entangle value objects from control objects.)
Oh, perhaps I should explain it a bit clearer? What did you mean by the Python stack? The hardware machine stack? What do we have at the moment: The stack is the linked list of frames. Every frame has a local Python evaluation stack. Calls of Python functions produce a new frame, and the old one is put beneath. This is the control stack. The additional info on the hardware stack happens to be a parallel friend of this chain, and currently holds extra info, but this is an artifact. Adding the current Python stack level to the frame makes the hardware stack totally unnecessary. There is a possible speed loss, anyway. Today, the recursive call of ceval2 is optimized and quite fast. The non-recursive Version will have to copy variables in and out from the frames, instead, so there is of course a little speed penalty to pay. 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