headers
Kuhl, Frederick S. | 23 Sep 2005 14:59
Picon
Favicon

RE: Announcing RIFE/continuations, pure Java continuations for everyone


>> Geert,
>> Sorry. Wasn't very explicit. We have a simulation framework that
>> consists of an executive and a bunch of logical processes
(simulation
>> entities). The logical processes perform cooperative multi-tasking,
>> which means this: A logical process runs until it wants to wait for
>> simulation time to pass. It asks the executive to suspend its
>> execution. The executive decides on another logical process to run,

>> and
>> resumes that process's execution at the point where it had stopped.
>> Eventually that process gives up running and asks the executive to
>> suspend it. So at any point either the executive is choosing 
>a logical
>> process to run, or some process is running. All the other logical
>> processes are suspended. Their suspended state could be 
>represented by
>> a suitable continuation. A process never has more than one  
>> continuation
>> at a time, nor does a continuation need to be resumed more than
once.
>>
>
>You mean something like this?
>
>      final Continuation continuation = Continuation.startWith(new  
>Runnable() {
>           public void run() {
>              // calculate
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kuhl, Frederick S. | 23 Sep 2005 14:50
Picon
Favicon

RE: Announcing RIFE/continuations, pure Java continuations for everyone

Geert,
Thanks. Each logical process does have the same entry point at the
beginning of its execution. And each logical process, when it asks to
be suspended, has called back into the same method. But the processes
will have different things on their stacks. Sounds like a good
application.

I'll add my request for a how-to! Thanks you for making the code
available.

Fred 

>-----Original Message-----
>From: Geert Bevin [mailto:gbevin@...] 
>Sent: Friday, September 23, 2005 8:43 AM
>To: dev@...
>Subject: Re: [continuation-dev] Announcing RIFE/continuations, 
>pure Java continuations for everyone
>
>Hi Fred,
>
>to me that looks a perfect use-case for the use of continuations  
>since you effectively retain the execution state and pause/resume the

>execution. You just have to lake sure that each process has the same  
>point of entry (execute method for instance). One of the current  
>limitations is also that we deliberately didn't implement  
>continuations support for anything else but the point of entry  
>method. This restriction will be lifted soon though.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kuhl, Frederick S. | 23 Sep 2005 14:34
Picon
Favicon

RE: Announcing RIFE/continuations, pure Java continuations for everyone

Geert,
Sorry. Wasn't very explicit. We have a simulation framework that
consists of an executive and a bunch of logical processes (simulation
entities). The logical processes perform cooperative multi-tasking,
which means this: A logical process runs until it wants to wait for
simulation time to pass. It asks the executive to suspend its
execution. The executive decides on another logical process to run, and
resumes that process's execution at the point where it had stopped.
Eventually that process gives up running and asks the executive to
suspend it. So at any point either the executive is choosing a logical
process to run, or some process is running. All the other logical
processes are suspended. Their suspended state could be represented by
a suitable continuation. A process never has more than one continuation
at a time, nor does a continuation need to be resumed more than once.

Do the Rife continuations appear to be a candidate for doing this?

Fred

>-----Original Message-----
>From: Geert Bevin [mailto:gbevin@...] 
>Sent: Friday, September 23, 2005 8:26 AM
>To: dev@...
>Subject: Re: [continuation-dev] Announcing RIFE/continuations, 
>pure Java continuations for everyone
>
>Hi Fred,
>
>euhm, you kinda lost me there ... I have no clue what you're talking  
>about ;-)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kuhl, Frederick S. | 23 Sep 2005 14:24
Picon
Favicon

RE: Announcing RIFE/continuations, pure Java continuations for everyone

Geert,
I'm still subscribed, and this is great news. Does it make sense to try
to apply this to coroutines to support simulation?

Fred Kuhl 

>-----Original Message-----
>From: Geert Bevin [mailto:gbevin@...] 
>Sent: Friday, September 23, 2005 4:49 AM
>To: dev@...
>Subject: [continuation-dev] Announcing RIFE/continuations, 
>pure Java continuations for everyone
>
>Hi everyone,
>
>I'm not sure people are still actually subscribed to this list, but  
>you never know.
>
>RIFE and WebWork worked together to extract the continuations engine  
>of RIFE into a reusable library. More information about this is my  
>blog post:
>http://rifers.org/blogs/gbevin/2005/9/23/announcing_rifecontinuations
>
>I thought this might interest some people.
>
>Best regards,
>
>Geert
>
>--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Geert Bevin | 23 Sep 2005 10:49
Favicon

Announcing RIFE/continuations, pure Java continuations for everyone

Hi everyone,

I'm not sure people are still actually subscribed to this list, but  
you never know.

RIFE and WebWork worked together to extract the continuations engine  
of RIFE into a reusable library. More information about this is my  
blog post:
http://rifers.org/blogs/gbevin/2005/9/23/announcing_rifecontinuations

I thought this might interest some people.

Best regards,

Geert

--
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
Permalink | Reply | 5 comments |
headers
Jakob Praher | 30 Oct 2004 18:29
Picon
Favicon

[continuations] status of continuations project

note: this is a cross post to the groovy-dev mailing list, since I haven't got any response from the
coninuations list

hi all,

since there hasn't been any traffic since august, I am wondering about
the status of the project.

I think the idea to submit this as a JSR would be nice.

Some questions that come to my mind:

* What's your primary aim for continuation support:
 -> have an explicit API (set of interfaces/classes) for continuations
which everybody agrees on (like a java.util.continuation. package)

 -> use existing byte code transformation for transparent cont. support
(for instance with the help of annotations)

 -> introduce continuation to java at the vm level (this could be
prepared to be introduced in a future jvm version (like with a special
bytecode for this) 

[ personally I favor the last, but this will be a hard way to get there,
since the JCP and SUN especially is pretty reluctant to change/enhance
the bytecode format. On the other hand, it could be implemented like the
class constant introduced in 1.5, which btw do break backward
compatibility, since an old jvm won't understand a constant class
literal and won't load a class marked with that version number anyway]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jakob Praher | 27 Oct 2004 23:32
Picon
Favicon

status of continuations project

hi all,

since there hasn't been any traffic since august, I am wondering about
the status of the project.

I think the idea to submit this as a JSR would be nice.

Some questions that come to my mind:

* What's your primary aim for continuation support:
 -> have an explicit API (set of interfaces/classes) for continuations
which everybody agrees on (like a java.util.continuation. package)

 -> use existing byte code transformation for transparent cont. support
(for instance with the help of annotations)

 -> introduce continuation to java at the vm level (this could be
prepared to be introduced in a future jvm version (like with a special
bytecode for this) 

[ personally I favor the last, but this will be a hard way to get there,
since the JCP and SUN especially is pretty reluctant to change/enhance
the bytecode format. On the other hand, it could be implemented like the
class constant introduced in 1.5, which btw do break backward
compatibility, since an old jvm won't understand a constant class
literal and won't load a class marked with that version number anyway]

* ATCT claims that its technology is patent pending[1], what does that
mean to an open source implementation of that?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jakob Praher | 27 Oct 2004 22:46
Picon
Favicon

status of continuations project

hi all,

since there hasn't been any traffic since august, I am wondering about
the status of the project.

I think the idea to submit this as a JSR would be nice.

Some questions that come to my mind:

* What's your primary aim for continuation support:
 -> have an explicit API (set of interfaces/classes) for continuations
which everybody agrees on (like a java.util.continuation. package)

 -> use existing byte code transformation for transparent cont. support
(for instance with the help of annotations)

 -> introduce continuation to java at the vm level (this could be
prepared to be introduced in a future jvm version (like with a special
bytecode for this) 

[ personally I favor the last, but this will be a hard way to get there,
since the JCP and SUN especially is pretty reluctant to change/enhance
the bytecode format. On the other hand, it could be implemented like the
class constant introduced in 1.5, which btw do break backward
compatibility, since an old jvm won't understand a constant class
literal and won't load a class marked with that version number anyway]

* ATCT claims that its technology is patent pending[1], what does that
mean to an open source implementation of that?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Schuhegger | 26 Aug 2004 08:22
Picon
Picon

[continuation-dev] my interest in continuations

hi,

i've read the list archive and i see that there are several opinions on 
where to go.

my personal interest in continuations is to use them for the workflow in 
a web application. i've already had a look at using SISC for handling 
the workflow, but i work in a team where nobody else was ever even in 
touch with a functional programming language nor did anybody ever hear 
of continuations.

if we would start the project from scratch i guess that rife would be a 
natural choice, but the application is already several years old and 
uses a "framework" developed in house. therefore throwing away what we 
have and switch over to rife is also not an option.

in my opinion the approaches that SISC, the cocoon javascript solution 
and from what i've read on this list the ACTC idea are quite similar in 
that they use an interpreter in order to implement continuations on top 
of the java vm. but i also think that the right way to go for the 
continuations in java effort is to propose extensions to the jvm so that 
continuations can be implemented more easily and higher performant even 
in pure java. this is like SISC uses the garbage collector from the jvm 
and does not implement its own. the jvm should provide a common 
infrastructure for handling continuations.

then i've seen the question coming up if continuations should be able to 
be migrated to another vm. i would say that continuations should not be 
restricted in order to make them migratable, e.g. a continuation does 
not have to be serializable, but a programmer should be able to program
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Schuhegger | 26 Aug 2004 08:24
Picon
Picon

[continuation-dev] my interest in continuations

hi,

i've read the list archive and i see that there are several opinions on
where to go.

my personal interest in continuations is to use them for the workflow in
a web application. i've already had a look at using SISC for handling
the workflow, but i work in a team where nobody else was ever even in
touch with a functional programming language nor did anybody ever hear
of continuations.

if we would start the project from scratch i guess that rife would be a
natural choice, but the application is already several years old and
uses a "framework" developed in house. therefore throwing away what we
have and switch over to rife is also not an option.

in my opinion the approaches that SISC, the cocoon javascript solution
and from what i've read on this list the ACTC idea are quite similar in
that they use an interpreter in order to implement continuations on top
of the java vm. but i also think that the right way to go for the
continuations in java effort is to propose extensions to the jvm so that
continuations can be implemented more easily and higher performant even
in pure java. this is like SISC uses the garbage collector from the jvm
and does not implement its own. the jvm should provide a common
infrastructure for handling continuations.

then i've seen the question coming up if continuations should be able to
be migrated to another vm. i would say that continuations should not be
restricted in order to make them migratable, e.g. a continuation does
not have to be serializable, but a programmer should be able to program
(Continue reading)

Permalink | Reply | 0 comments |

Gmane