1) When you access the "current" continuation, it captures the call stack up to but not including the current method (and makes a (shallow) copy of it). The current method continues as normal. The reason for making a copy is to prevent further modification of the captured continuation stack as the method call stack unwinds (see below).
2) To resume a continuation you invoke it - like a method call through reflection - and you can pass an object to this call (which becomes the return value of the method where the continuation was created).
3) Before the continuation is resumed another copy of the stack is made (the original continuation stack is treated as an immutable object). This makes it possible to invoke the continuation more than once.
It's possible to make the stack copying occur lazily as an optimization (in case another continuation is invoked the method at the top of the stack never returns so copying the remaining frames isn't necessary).
Chris
Brian McCallister wrote:
I will be surprised if continuations based around the Cocoon javaflow implementation don't leak into Groovy CVS based on the amount of chatter in #groovy about continuations.
I know James wants this very much, and hacked out a way to do it via exceptions once (and hacked is the correct word), but has been waiting for generalized Java continuations rather than hack it into the language.
-Brian
On Apr 4, 2004, at 2:32 PM, Christopher Oliver wrote:
Stefano Mazzocchi wrote:
Antonio Gallardo wrote:It should be _fairly_ straightforward. The only tricky part I see is controlling the byte-code transformation. All methods in the call-chain leading from the method invoked by Interpreter.callFunction() to sendPageAndWait() or any other method that creates a continuation must be instrumented. The current implementation only instruments classes that implement the interface "Continuable". In the case of scripting languages like Groovy, Jython, or Rhino, pretty much the entire interpreter and all classes generated from scripts will need to be instrumented. Any callbacks from non-instrumented code to instrumented code will break the continuation.
Hi:
Hi:
Some of us wanted to see Groovy support in Cocoon. Now we can "play" a
little with Groovy using the recently added support for Groovy script
generator under the BSF block. More info about how to use it is here:
http://cocoon.apache.org/2.1/userdocs/generators/script- generator.html
SITEMAP CONFIGURATION FOR GROOVY: ======================
In components section add:
<map:generator name="script"
src="org.apache.cocoon.generation.ScriptGenerator"
logger="sitemap.generation.scriptgenerator">
<!-- Groovy support -->
<add-languages>
<language name="groovy" src="org.codehaus.groovy.bsf.GroovyEngine">
<extension>groovy</extension>
<extension>gy</extension>
</language>
</add-languages>
</map:generator>
I hope this will have a good welcome in the Cocoon Community.
Best Regards,
Antonio Gallardo
Next I would like to see is a groovy implementation of flow ;-)
One approach might be to instrument the build system to rename class files that require instrumentation to have a special extension (".iclass" or whatever) making them invisible to normal class loaders but recognizable to the class loader that performs the byte-code transformation.
Another possible approach is to provide a configuration to the class loader using wildcard specifications (e.g. "groovy.*", etc) to allow it to identify which classes to instrument.
Chris
