cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <>
Subject Re: Groovy support in Cocoon
Date Tue, 06 Apr 2004 10:25:35 GMT
Am Mo, den 05.04.2004 schrieb Christopher Oliver um 19:18:
> After thinking about this a few more minutes over coffee, I like the 
> idea of constructing the continuation stack as the JVM stack is unwound 
> (that way "normal" code doesn't encounter any overhead other than the 
> tests for isRestoring() and isCapturing(). So perhaps what we could do 
> when Continuation.getCurrentContinuation() is called is to unwind the 
> JVM stack, constructing the continuation stack, and then immediately 
> restore it returning the newly created continuation object (which will 
> contain a copy of the continuation stack we just created). If the 
> continuation object is invoked we will again unwind the current JVM 
> stack, but this time there's no need to capture it.

Yes, the hole idea was to leave the code as it is and only test after
every invocation if the Continuation goes into the state "capturing".
And you can check at the compile time if the destination object is
"continuable". So you must only check isCapturing() after method calls
which are "continuable".

But there is a pitfall, see

        calls                            calls
MyFlow -------> MyClass(uninstrumented) -------> MyFlow -->

In this case the complete stacktrace can't be restored. So I must
add a flag to signal that I can't suspend the continuation. But
this should be easily implemented.

To come back to BSF and Groovy, I think a class like a ContinationProxy
should do the work.

ContinuableBSFInterpreter -> Groovy -> ContinationProxy -> Groovy Class

The ContinuationProxy can assign a new Continuation to the thread
and invoke the Groovy Class.


View raw message