« Return to Thread: Continuation mechanism in RIFE?
Re: Continuation mechanism in RIFE?
by liu chang
::
Rate this Message:
On 1/25/06, Geert Bevin <gbevin@...> wrote:
> Hi Lui,
>
> > As I understand RIFE supports some form of continuation using pure
> > Java, and in the process rife needs to be able to clone the stack. But
> > I also understand that java forbids the inspection of the stack by a
>
> Indeed.
>
> > running program. So, how is stack cloning exactly done in rife? What
> > exactly does the bytecode manipulator do? Are there any limitations or
>
> For the variable stack, the bytecode manipulation adds the required
> instructions to maintain a parallel stack that mimics the standard
> Java stack. It is this stack that is cloned.
>
> > potential problems regarding effeciency etc? And how extensible is the
>
> It turns out to be very efficient as long as you don't put a huge
> amount of data in your local variable stack. We've used it on large
> production sites without any negative impact.
>
> > approach to other frameworks/languages? Implementing continuation in
>
> It can and work is underway to make this reusable with the RIFE/
> Continuations sub-project.
>
> > pure java isn't easy, so maybe there is some research paper that talks
> > about the rife approach?
>
> Some has been inspired by what is explained here:
> http://www.cs.kuleuven.ac.be/~eddy/BRAKES/brakes.html
>
> > I looked through the rife site but found no mention of this. And I
>
> Indeed, there's no detailed documentation about it available (yet).
>
> > have no clue where to start looking in the rife-continuation source
> > code :P Some general hints are greatly appreciated. :)
>
> On a small side-note, RIFE/Continuations as an independent project is
> considered experimental as it's a quick attempt at extracting the
> continuations engine for use inside other frameworks, like for
> example WebWork. RIFE itself hasn't reintegrated the extracted
> continuations source code yet, so the engine inside RIFE is more
> stable for the moment.
>
> Best regards,
>
> Geert
>
Hi Geert, thanx for the quick reply.
I just read the brakes paper that was linked from your post, kinda
like one that I've read,
http://homepage.mac.com/t.sekiguchi/paper/ehbook01.pdf, though it uses
exception instead of normal return :)
I looked into the EngineClassLoader class which i believe is the main
class loader? It seems to me that only classes Element and
ElementAware are modified to handle continuation. While this looks
great for performance reasons it puzzles me a lot. What happens if
there're non-element classes on the stack? How can the continuation
captured correctly and restored later when these classes are not
"coorperating"? Or does the operation of rife somehow guarantees that
only Elements will be on the stack? (sorry I'm not very familiar with
the workings of rife)
btw my name is "Liu" not "Lui" :P
Thanks again Geert for the great work of Rife :)
Liu Chang
> --
> Geert Bevin Uwyn bvba
> "Use what you need" Avenue de Scailmont 34
> http://www.uwyn.com 7170 Manage, Belgium
> gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
>
> PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
> Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>
> Hi Lui,
>
> > As I understand RIFE supports some form of continuation using pure
> > Java, and in the process rife needs to be able to clone the stack. But
> > I also understand that java forbids the inspection of the stack by a
>
> Indeed.
>
> > running program. So, how is stack cloning exactly done in rife? What
> > exactly does the bytecode manipulator do? Are there any limitations or
>
> For the variable stack, the bytecode manipulation adds the required
> instructions to maintain a parallel stack that mimics the standard
> Java stack. It is this stack that is cloned.
>
> > potential problems regarding effeciency etc? And how extensible is the
>
> It turns out to be very efficient as long as you don't put a huge
> amount of data in your local variable stack. We've used it on large
> production sites without any negative impact.
>
> > approach to other frameworks/languages? Implementing continuation in
>
> It can and work is underway to make this reusable with the RIFE/
> Continuations sub-project.
>
> > pure java isn't easy, so maybe there is some research paper that talks
> > about the rife approach?
>
> Some has been inspired by what is explained here:
> http://www.cs.kuleuven.ac.be/~eddy/BRAKES/brakes.html
>
> > I looked through the rife site but found no mention of this. And I
>
> Indeed, there's no detailed documentation about it available (yet).
>
> > have no clue where to start looking in the rife-continuation source
> > code :P Some general hints are greatly appreciated. :)
>
> On a small side-note, RIFE/Continuations as an independent project is
> considered experimental as it's a quick attempt at extracting the
> continuations engine for use inside other frameworks, like for
> example WebWork. RIFE itself hasn't reintegrated the extracted
> continuations source code yet, so the engine inside RIFE is more
> stable for the moment.
>
> Best regards,
>
> Geert
>
Hi Geert, thanx for the quick reply.
I just read the brakes paper that was linked from your post, kinda
like one that I've read,
http://homepage.mac.com/t.sekiguchi/paper/ehbook01.pdf, though it uses
exception instead of normal return :)
I looked into the EngineClassLoader class which i believe is the main
class loader? It seems to me that only classes Element and
ElementAware are modified to handle continuation. While this looks
great for performance reasons it puzzles me a lot. What happens if
there're non-element classes on the stack? How can the continuation
captured correctly and restored later when these classes are not
"coorperating"? Or does the operation of rife somehow guarantees that
only Elements will be on the stack? (sorry I'm not very familiar with
the workings of rife)
btw my name is "Liu" not "Lui" :P
Thanks again Geert for the great work of Rife :)
Liu Chang
> --
> Geert Bevin Uwyn bvba
> "Use what you need" Avenue de Scailmont 34
> http://www.uwyn.com 7170 Manage, Belgium
> gbevin[remove] at uwyn dot com Tel +32 64 84 80 03
>
> PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
> Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
>
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>
« Return to Thread: Continuation mechanism in RIFE?
| Free Forum Powered by Nabble | Forum Help |