[pypy-dev] question on rpython stack reconstruction feature

alan yung 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)
> function,
> > 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
function)

from pypy.translator.stackless.code import UnwindException

def freeze(space):
    global storedExecutionContext

    ec = space.getexecutioncontext()

    storedExecutionContext.copy(ec)

    while len(ec.framestack.items) > 1:
        ec.framestack.pop()

    raise UnwindException()
freeze.unwrap_spec = [ObjSpace]


Now I guess it should stop executing the current python level functions,
shouldn't it?


>
>
> A bientot,
>
> Armin.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20090530/6aa023cb/attachment.html>


More information about the Pypy-dev mailing list