On Mon, Dec 7, 2009 at 11:43 PM, Bob Rogers <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
