runops speculation

[Allison Randal]

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.

Allison