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

Andrew Whitworth wknight8111 at gmail.com
Mon Dec 7 16:29:54 UTC 2009


On Mon, Dec 7, 2009 at 11:16 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> A point of clarification:  I believe it's only the "and enforce"
> part of this statement that requires a massive refactoring of PIR code.
> We can certainly define an API that says that well-behaved exception
> handlers must have explicit end points, and any handlers that don't
> follow that API have to live with (or otherwise "handle") the
> consequences.

I won't fight this point. It's always easier to fix a bug if the
compiler helps you locate it. If everybody is fine with the compiler
offering no help in this regard, then that's a suitable solution.

> In particular, I think that if we simply provide an opcode or method
> that an ExceptionHandler (or Continuation?) can use to explicitly
> request the longjmp back into the original runloop, then we solve
> the largest part of the current issue.  In other words, we establish a
> convention -- enforcement to come later -- that well-behaved
> ExceptionHandlers either return control to the thrower or
> explicitly signal (via opcode or method) that they are resuming
> execution in the original context/runloop.

Herein lies a slightly different problem. Once we leave the inner
runloop and unwind the C stack, we cannot return. For clarity, I
suppose we could attempt it but the C standard explicitly says the
behavior "is undefined" [1] and I can tell you from experience that on
my of our target platforms the result will be horrible.

In this case we stay in the inner runloop to execute the handler and
then when an "exception handler end" op is executed we can make
informed decisions about where to go.

--Andrew Whitworth

[1] http://www.opengroup.org/onlinepubs/007908799/xsh/longjmp.html


More information about the parrot-dev mailing list