Re: coroutines and continuations ( in Python? - long discussion )
Steven D. Majewski (sdm7g@elvis.med.virginia.edu)
Fri, 6 May 1994 18:30:15 -0400
On May 5, 23:29, Tim Peters wrote:
>
> > > [tim]
> > > ... the _C_ runtime stack is also part of the current continuation ...
>
> > [steve]
> > ... the _C_ runtime stack is NOT a part of the context or current
> > continuation - only the Python block and argument stacks and the
> > current byte-code instruction pointer. We only have to keep state
> > for the virtual machine - that's what makes it portable.
>
> I believe you're going to find this isn't true, at both shallow and deep
> levels. Guido mentioned the "deep" level: a call to a Python routine may
> end up calling an external C routine that in turn calls another Python
> routine. The continuation at that point is a mess.
>
> The "shallow" level comes up in _any_ call today. E.g., here's the whole
> program:
>
> def f():
> # want to save a continuation here
> return 1
>
> f()
>
> The byte-code for the call to f calls the C routine call_object, which
> in turn calls the C routine call_function, which in turn (an indirect
> recursion) calls eval_code again. So by the time we get to the comment,
> we have 3 C frames stacked up as part of the continuation. The
> RETURN_VALUE code doesn't currently stay within the evaluation loop: it
> exits eval_code, unwinding the C stack frames until it gets back to the
> call_object call in the top-level invocation of eval_code.
But 'SUSPEND' opcode would do a return from ceval just like 'RETURN' opcode,
except it would return a ( retval, cont-obj ) tuple instead of just
retval. [ Where cont-obj is an object containing the current
frameobject, plus block-pointer, stack-pointer, and last-instruction-
pointer ]. The other difference between RETURN is that SUSPEND would
not do a POP/DECREF on the contents of the python stack. That code would
have to be in the destructor for cont-obj.
Ceval would return and the C-stack would unwind, leaving behind a
"restartable" python frame. ( and ceval would have to be modified
to accept such an object, and to SKIP current_frame = newframeobject,
etc., and to restore (virtual machine) state from that object. )
So I'm not *completely* convinced yet, but you guys have raised enough
good points that you've got me worried! That's why I raised the
issue in the first place: it looked TOO EASY and I was suspicious.
( However, the LESS easy it looks, the MORE I begin to believe it! ;-)
-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --