cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)
Date Thu, 11 Apr 2002 11:50:24 GMT
Ovidiu Predescu wrote:

>On Wed, 10 Apr 2002 10:14:24 +0200, Sylvain Wallez <>
>>Ovidiu Predescu wrote:
>>>Please do a cvs update and check out the calculator sample again. I've
>>>reverted back to using callCC in JavaScript instead of a new API, a
>>>Continuation object, provided by Christopher Oliver in his modified
>>>Rhino engine. I need to test the later a bit more before using it.
>>Ovidiu, can you tell us the status of the work of Christopher Oliver, as 
>>the continutation-enabled Rhino becomes a critical part of the flow engine :
>>- are sources available ?
>>- under which licence (same MPL as Rhino)
>>- is it/will it be integrated into the main Rhino code base ?
>Christopher's work is available in source form from:


>The package also contains a pre-built, ready to use, jar file. The
>license is still MPL, and I don't think is possible to change it.

MPL is good. I was wondering if it was something else.

>At this point, the primary maintainers of Rhino seem to be concerned
>with two things:
>- the performance implications of the continuations code has on the
>interpreted engine.
>- the fact that continuations are available in interpreted mode
>Rhino has two ways of running JavaScript scripts. The first one is
>translating the script in a structure of internal objects, which are
>then "executed". The second approach, a lot faster that the first one,
>translates the JavaScript scripts in internal Java classes, which are
>compiled to bytecodes on-the-fly and executed as normal Java code.
>Adding support for continuations in the compiler mode is not possible,
>due to the impossibility to manipulate the Java stack frame.
>I believe at this point, Norris Boyd and other Rhino maintainers are
>waiting for the continuations code to stabilize, and have all the bugs
>removed. In the past month Christopher came up with new versions every
>other day almost ;-). Some of them had major bugs, and unless somebody
>like us tests the code extensively it may be difficult to remove them.

Classical chicken-and-egg problem : people don't want to use something 
that's not stable, and that thing needs users to stabilize. Let's 
stabilize it with Cocoon !

>One of the implications for us is that once Schecoon is merged onto
>the main trunk, we'll have to use this engine instead of the 1.5R3
>version we currently use.

If the compiled engine is still available in the patched version, then 
this should be no problem : use interpreted mode for the flow, and 
compiled mode everywhere else.

>I certainly hope Christopher's work will get into the main trunk, so
>that we're not stuck with an unsupported version.
>Another alternative, which I still need to explore, is to continue the
>development on the language I proposed a while ago. This will give us
>much more control over what features we need, and we can possibly have
>more optimizations implemented. Rhino is much slower when it comes to
>continuations than SISC, the Scheme interpreter I was initially used
>in Schecoon.
>And there are certain optimizations which can be done to minimize the
>size of the captured continuations, which are simply not possible in
>Rhino without major changes. Controlling what gets captured in a
>continuation at the language level would also help developers a
>lot. For example it would be nice to have language constructs that
>tell that a variable's value should not be captured in a continuation,
>and how its value could be restored after the continuation is
>resurrected. At this point this is just some food for thought, I need
>to look more closely into these issues.

That would be an equivalent of the "transient" keyword for local variables.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message