cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: Brakes (was: [control flow] changes and new sample)
Date Fri, 13 Sep 2002 12:43:18 GMT
Tim Coninx wrote:

>On Wed, Sep 11, 2002 at 04:48:42PM +0200, Sylvain Wallez wrote:
>  
>
>>Tim Coninx wrote:
>>
>>We are *very serious* at using something like Brakes in Cocoon. The use 
>>case is however a little bit different than Brakes : we want to 
>>implement continuations, which are the capability for a program to 
>>interrupt itself and be resume later in the state where it was 
>>interrupted. The main difference (as far as I understand) with Brakes is 
>>that program interruption is not triggered externally in our case.
>>    
>>
>
>Actually, this was the main reason brakes was developed. Correlate was a
>project exploring the concept of 'Active Objects', object that repeat a
>certain autonomous behaviour.
>The main difficulty here was that a separate scheduler from the one the
>JVM offers had to be used, to gain control of the scheduling of the
>active objects opposed to the core system.
>
>The first version of Brakes (which didn't have a name at that point)
>required every active object to Yield (effectively calling his own
>overridden yield method). This method would set the state of the active
>object to 'saving' and make the instrumented bytecode return every
>method in the call trace, while saving every stackframe. When the active
>object is rescheduled, the state is set to restoring, and the call trace
>rebuilds up to the point where the yield method was called, at which
>point the state is set back to normal. Then the next instruction (the
>one following the yield method) is called.
>
>This version, which is much faster (or less slow ;-) than the last version,
>is called brakes-serial (as opposed to brakes-parallel), and is included
>in the main brakes release.
>
>  
>
>>>About licensing: because Brakes was abandoned so early, it is covered
>>>under the same proprietary license as it's parent project, Correlate
>>>      http://www.cs.kuleuven.ac.be/~distrinet/projects/CORRELATE/
>>>
>>>However, (again when you are serious about using brakes into Cocoon) it
>>>will be possible to decouple Brakes from Correlate and embed the
>>>subproject (Brakes) into Cocoon, or at least release it seperately under
>>>the APL.
>>>
>>>      
>>>
>>We would be *very interested* in that. Is some license change possible 
>>so that we can at least look at the source code ?
>>    
>>
>
>I'll start the administrative procedures (getting in touch with the
>group leader) now. In the mean time, I'll send you (personally) the
>source, so you can have a first look at it.
>  
>

Well received. Thank you very much, Tim. I will study this with great 
interest.

What can be the result of the administrative procedures you're talking 
about ? Can we forsee a relicensing under the Apache licence ? If such 
licensing is possible, what about considering a donation to the BCEL 
project, as Brakes has a broader potential than Cocoon ?

And finally, is someone still working on Brakes, i.e. can we expect some 
help from you or your group at least to get started ?

Thanks for your answers, and of course for the sources.

Sylvain

-- 
Sylvain Wallez
  Anyware Technologies                  Apache Cocoon
  http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message