Q about TT #1091 (deprecate label-based exception handlers)

Andrew Whitworth wknight8111 at gmail.com
Tue Dec 8 13:08:01 UTC 2009


On Mon, Dec 7, 2009 at 11:43 PM, Bob Rogers
<rogers-perl6 at rgrjr.dyndns.org> 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.
> If each continuation keeps track of which runloop created it (which used
> to happen in order merely to detect attempts to exit an inferior
> runloop), and whether that runloop is still active, Parrot can easily
> use a longjmp to get out of the inner runloop(s).  Only a small amount
> of additional bookkeeping is required for keeping track of active
> runloops and their setjmp points, and the storage for that can be
> allocated on the C stack.

What happens if we try to jump back into an inferior runloop?

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.

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.

>   I was sorely tempted to hack this together several years ago, as it
> takes care of 100% of the nonlocal exit cases that a Common Lisp
> implementation must support -- for CL, the problem of getting back into
> that exited inner runloop never arises.  But I never did so, mostly
> because I thought it might reduce the priority of actually fixing the
> real problem, which is that inferior runloops prevent Parrot from being
> truly "continuation-based."  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.

You're also correct that the only real permanent solution is to ban
inferior runloops entirely. The path to do that, that I can see,
involves rewriting all nested execution paths in Lorito (which could
bring a number of other benefits as well). If this is becoming a pain
point, and I don't think particularly that it is, we might want to
push that discussion into high gear.

--Andrew Whitworth


More information about the parrot-dev mailing list