allison at parrot.org
Wed Feb 11 21:36:07 UTC 2009
Andrew Whitworth wrote:
> I've been thinking about this all night too. The problem that I keep
> running into is that you would have to call a setjmp in the runcore
> before calling any opcode that might cause a recursive call into the
> runcore. Because you have two methods of rentry: The opcode doesn't
> cause a recursive call to runops, so it returns to the core and
> continues like normal, or the opcode does cause a recursive call and
> needs to invoke the continuation. What happens in cases like a vtable
> override when both of these need to happen? The vtable override is
> invoked recursively and then returned to the point in the runcore
> where the vtable override was first called. What happens for recursive
> calls to these overrides, where we would end up with a long string of
> jump points to manage?
> I really like the idea, but I don't think I am seeing the big picture with it.
Eliminating that setjmp/longjmp is the central point. Instead of a C
control loop, continuing to the next runloop iteration is always a call
to a core "runops" coroutine.
This is long-term speculation, not 1.0.
More information about the parrot-dev