From: "Patrick R. Michaud" <[email protected]>
Date: Mon, 7 Dec 2009 11:02:36 -0600
On Mon, Dec 07, 2009 at 11:29:54AM -0500, Andrew Whitworth wrote:
> Herein lies a slightly different problem. Once we leave the inner
> runloop and unwind the C stack, we cannot return.
That's fine. An exception handler that is going to resume
control to the thrower wouldn't execute the "return to original
runloop opcode" -- i.e., it would stay in the inferior runloop (as
it should).
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.
As a side benefit, this also makes continuations more useful
(i.e. less buggy) in all situations, not just those involving exception
handlers.
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.
-- Bob
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
