question on rpython stack reconstruction feature
I tried to use rstack's functions to reconstruct interpreter level stack like following.. http://sourceforge.net/tracker/?func=browse&group_id=58965&atid=489447&status=2 I've implemented them as interpreter level functions. In freeze(), I captured python level frame objects, and try to unwind the stack with stack_unwind, and in resume() I try to reconstruct the c frame stack with resume_state_create/invoke and python frame with cloned frames. But it seems like it doesn't take effect at all (I tested it under stackless enabled translated version of pypy) What am I doing wrong? Thanks.
Hi, On Wed, May 27, 2009 at 08:46:24PM -0700, alan yung wrote:
Sorry, your e-mail is hard to understand, probably because the link above seems to be wrong. It just points to the list of bugs for the Supybot project. Can you fix it and also explain a bit more what you are trying to achieve and why? Thanks! A bientot, Armin.
Hi, Thanks and sorry about the link. The right link is http://paste.pocoo.org/show/119296/ this. What I'm trying to do there is this: In the freeze() function, I want to stop executing the current python function, and copy the (python) frame stack, and unroll the python frame stack *and* interpreter level stack frame. In the resume() function, I want to continue executing the python function copied in freeze() function and reconstruct interpreter level stack using resume_state_create() and resume_state_invoke() function. On Thu, May 28, 2009 at 12:57 PM, Armin Rigo <arigo@tunes.org> wrote:
On May 28, 2009, at 5:10 PM, alan yung wrote:
On Thu, May 28, 2009 at 12:57 PM, Armin Rigo <arigo@tunes.org> wrote: Hi,
I think you forgot to answer why are you doing it? I don't know much about stackless but this seems very similar to what stackless does on pypy (which has stackless at the rpython/interpreter level). -- Leonardo Santagada santagada at gmail.com
On Fri, May 29, 2009 at 2:44 AM, Carl Friedrich Bolz <cfbolz@gmx.de> wrote:
I implemented a (mixed) module, and implemented those functions as interpreter level functions, and made them callable from application level. I called them from normal Python application (in stackless translated pypy vm) and the behaviour is that they don't have any effect. There's no (interpreter level/application level) stack unwinding or resuming. thanks.
Cheers,
Carl Friedrich
Hi Alan, On Fri, May 29, 2009 at 08:19:27AM -0700, alan yung wrote:
Ah, that's step 1. I see. As this is RPython code, it means that you cannot use some constructs -- in this case, the problem is that "if not freezed_executioncontext:" is constant-folded, so it is always True (which is of course not the case in a normal Python program). You don't have varying global lists in RPython, so you need to create a small class, create a global instance of it, and then you can read/write an attribute "freeze_executioncontext" on it. A bientot, Armin.
Thanks Armin. I fixed the code accordingly, and resume() function seems to be (somehow) working. However, freeze() function does not work the way I wanted. Following is how I fixed it. http://paste.pocoo.org/show/119851/ After translating pypy with stackless option with above code, I ran following python code def foo(): def foo2(): freeze() print "foo" foo2() def bar(): print "bar" resume() if __name__ == '__main__': foo() bar() resume() function needs to be fixed alittle bit, but when I run above code, I wanted it to print out "bar" first, and not "foo" but it prints out "foo" first. So, it seems like rstack.stack_unwind() function does not seems to work. Any thought? On Fri, May 29, 2009 at 9:13 AM, Armin Rigo <arigo@tunes.org> wrote:
Hi Alan, On Fri, May 29, 2009 at 08:23:52PM -0700, alan yung wrote:
So, it seems like rstack.stack_unwind() function does not seems to work.
It seems you misunderstood what rstack.stack_unwind() does. It flushes the C stack, but it has no visible effect apart from reducing the consumption of the C stack. A bientot, Armin.
On Sat, May 30, 2009 at 12:00 AM, Armin Rigo <arigo@tunes.org> 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?
A bientot,
Armin.
Hi Alan, On Sat, May 30, 2009 at 12:10:55AM -0700, alan yung wrote:
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. A bientot, Armin.
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.
Hi Alan, On Sat, May 30, 2009 at 02:15:06PM -0700, alan yung wrote:
raise UnwindException()
All you're archieving this way is confuse the system (and me). However, I think I get the idea. You want to interrupt the current thread completely, in the idea that later it can be restarted by your resume() function. You should not do that by raising UnwindException; just raise another exception you define locally. Of course you must then also catch it somewhere. A bientot, Armin.
participants (4)
-
alan yung
-
Armin Rigo
-
Carl Friedrich Bolz
-
Leonardo Santagada