On Mon, Dec 7, 2009 at 11:16 AM, Patrick R. Michaud <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
