[pypy-dev] question on rpython stack reconstruction feature
yung2.alan at gmail.com
Sat May 30 23:15:06 CEST 2009
> On Sat, May 30, 2009 at 12:10:55AM -0700, alan yung wrote:
> > But in the freeze() function, I also cleared app level frames like
> > following...
> > while len(ec.framestack.items) > 1:
> > ec.framestack.pop()
> > stack_unwind()
> > In that case, I thought this should stop executing the (app-level)
> > shouldn't it?
> No: as I said, stack_unwind() has no effect apart from keeping the usage
> of the C stack under control, so we can ignore it for the purpose of
> understanding how this code works. It just empties ec.framestack, but
> the real stack of interp-level calls is still there. So this code just
> creates a discrepancy between ec.framestack and the call stack -- and
> the call stack wins, as PyPy's interpreter is implemented using the call
> stack (like CPython's interpreter).
> Enabling stackless in this code changes this fact but at another level.
> It's like stack_unwind(): calling it has no visible effect from RPython
> code; it just temporary reduces the C stack depth. Similarly, Stackless
> in PyPy is implemented by calling stack_unwind() internally as needed,
> so that the C stack depth can be reduced -- but the PyPy interpreter is
> still written in a recursive style. "Reducing the C stack depth" mostly
> means copying a part of the C stack away into the heap, where it can be
> re-read later.
Oh I see. This is interesting.
If I do something like following (raising UnwindException in the freeze
from pypy.translator.stackless.code import UnwindException
ec = space.getexecutioncontext()
while len(ec.framestack.items) > 1:
freeze.unwrap_spec = [ObjSpace]
Now I guess it should stop executing the current python level functions,
> A bientot,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pypy-dev