From: Andrew Whitworth <[email protected]>
Date: Tue, 8 Dec 2009 08:08:01 -0500
On Mon, Dec 7, 2009 at 11:43 PM, Bob Rogers wrote:
> If unwinding the C stack is acceptable (and I agree that this
> handles most of the important cases), there is a simpler solution
> that doesn't require new opcodes, and that is to implement
> "downward" continuations . . .
What happens if we try to jump back into an inferior runloop?
In that case, we wouldn't be able to find the destination runloop, in
which case we should probably signal an error. (Which is problematic if
this happens during error handling, but dealing with errors during error
handling is a more general can of worms that needs to be addressed in
any case.)
Once we unwind the C stack we've lost track of whatever process was
happening at that time. Many such cases are VTABLE calls on
user-defined objects that are expected by the code to return a value.
If the C stack is unwound, there is nowhere to return a value to and
the whole program logic gets garbled up.
Normally, a nonlocal exit like this only happens when the program
decides it really has to get the hell out of there, and then nothing
else will do. The intent is really to abandon that part of the
computation, *avoiding* all of those pending exits. That is true
whether those exits are written in C or PIR, and whether or not more
than one runloop is involved.
That said, there probably ought to be a mechanism for disabling
unwinding through a specific runloop, in case the code that calls it
wants to insist on running its post-runloop cleanup code. That should
be a simple matter of making any such runloop pretend that it is the
outermost.
We'd need to make certain continuations invalid if the runloop they
point to has been unwound, and we would likely need to add mechanisms
to check the validity from PIR code (which seems like a lot of
overhead) and throw exceptions if we tried to invoke a continuation
that pointed to a bad place.
Actually, the overhead of checking during invocation is pretty small.
Parrot used to warn if trying to invoke a continuation that belonged to
a different runloop. In the typical case, the test involved a single
integer comparison. The trick is to use integer UIDs to identify
runloop instantiations. (I don't know when this check was removed,
never mind why, but you can see it in Continuation:invoke as of
continuation.pmc rev 14928, e.g. Look for "oops". ;-)
> . . . Since it seems that we are stuck with inferior runloops for
> the foreseeable future, maybe half a glass would be better than
> none.
I would like to see more information from you about this idea. I can't
imagine that it's going to resolve all our problems but it sounds
quite interesting nonetheless and aligns with some ideas I've been
kicking around.
OK, I'll try to elaborate when I have more time. With any luck, I may
get a chance to hack up a PoC this weekend.
-- Bob
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
