continuations

[Sean T Allen]

wondering if rubinius is going to support continutations ( and if that
is already in place, if it will continue to do so. )

[Wilson Bilkovich]

On Tue, Mar 18, 2008 at 2:25 PM, Sean T Allen <se...@ardishealth.com> wrote:
>
> wondering if rubinius is going to support continutations ( and if that
> is already in place, if it will continue to do so. )
>

Yep. Already does, and intends to continue to do so.

[Sean Allen]

now that is music to my ears.

[Chuck Remes]

If you have a good use-case for continuations, you should send it to
ruby-core. The only reason (as far as I know) that Matz has indicated
continuations are disappearing in 2.0 is related to the lack of
requests for that feature. He has said that if he had a good use-case,
it would likely stay in the language.

cr

[Sean Allen]

does continuation based web application count as enough of a use case?
we have old legacy code that is in dire need of a rewrite and part of it
is just screaming out to be done as continuations.

[Werner Schuster (murphee)]

Chuck Remes wrote:
> If you have a good use-case for continuations, you should send it to
> ruby-core. The only reason (as far as I know) that Matz has indicated
> continuations are disappearing in 2.0 is related to the lack of
> requests for that feature. He has said that if he had a good use-case,
> it would likely stay in the language.
>
>

Well, they made it into 1.9, despite early concerns that they might not
due to the native threading.
The bigger problem is with implementations like JRuby and IronRuby,
which don't support them and aren't likely to anytime soon.

Actually, I wonder if some of the features Continuations would be used
for couldn't be done with Fibers/Coroutines which are in 1.9.

[Christian Vest Hansen]

On 3/19/08, Werner Schuster (murphee) <werner....@gmail.com> wrote:
>
> Chuck Remes wrote:
> > If you have a good use-case for continuations, you should send it to
> > ruby-core. The only reason (as far as I know) that Matz has indicated
> > continuations are disappearing in 2.0 is related to the lack of
> > requests for that feature. He has said that if he had a good use-case,
> > it would likely stay in the language.
> >
> >
>
> Well, they made it into 1.9, despite early concerns that they might not
> due to the native threading.
> The bigger problem is with implementations like JRuby and IronRuby,
> which don't support them and aren't likely to anytime soon.

Rhino, the JavaScript engine for Java, has continuations, so I suppose
it is at least possible for JRuby to implement them as well.

>
> Actually, I wonder if some of the features Continuations would be used
> for couldn't be done with Fibers/Coroutines which are in 1.9.
>
>
>
> >
>

--
Venlig hilsen / Kind regards,
Christian Vest Hansen.

[Charles Oliver Nutter]

Christian Vest Hansen wrote:
> On 3/19/08, Werner Schuster (murphee) <werner....@gmail.com> wrote:
>> Chuck Remes wrote:
>> > If you have a good use-case for continuations, you should send it to
>> > ruby-core. The only reason (as far as I know) that Matz has indicated
>> > continuations are disappearing in 2.0 is related to the lack of
>> > requests for that feature. He has said that if he had a good use-case,
>> > it would likely stay in the language.
>> >
>> >
>>
>> Well, they made it into 1.9, despite early concerns that they might not
>> due to the native threading.
>> The bigger problem is with implementations like JRuby and IronRuby,
>> which don't support them and aren't likely to anytime soon.
>
> Rhino, the JavaScript engine for Java, has continuations, so I suppose
> it is at least possible for JRuby to implement them as well.

I believe Rhino only supports continuations in interpreted mode, and not
if you make calls into Java libraries. We could support them with the
same restrictions.

- Charlie

[Chuck Remes]

I don't know. Why don't you email that to ruby-core and see what they
say? Unfortunately, I'm not the arbiter of what goes in or what comes
out of the language. :-)

cr

[Jason Yates]

> > does continuation based web application count as enough of a use case?
> > we have old legacy code that is in dire need of a rewrite and part
> > of it
> > is just screaming out to be done as continuations.
>
> I don't know. Why don't you email that to ruby-core and see what they
> say? Unfortunately, I'm not the arbiter of what goes in or what comes
> out of the language. :-)

Continuations or not, aren't web continuations more an issue with
whether you can save and restore the call stack? In addition, the
performance penalty you'd incur with this on Ruby C call stack
compared to say Rubinius as it being stackless. Or maybe I'm just
blowing smoke.

--
Jason Yates
jay...@gmail.com

[Sean Allen]

On Mar 20, 2008, at 4:56 PM, Jason Yates wrote:

> In addition, the
> performance penalty you'd incur with this on Ruby C call stack
> compared to say Rubinius as it being stackless

is there something missing from this thought?
i'm horribly confused by it right now.

[Ryan Mulligan]

If you take "? In addition," and replace it with "or" it makes sense. Always use your ors with whethers.

[Eric Hodel]

In ruby 1.8 the expensive part was not the call stack, but the over-
eagerness of closures keeping unnecessary objects around to support a
feature of eval.

[Oleg Andreev]

BTW, betterruby.wordpress.com says:

"Tasks are very similar to threads, but lack pre-emption or
scheduling. In practice, they are similar to Ruby 1.9 fibers, although
unlike fibers, there is currently no way to co-operatively multi-task
(or yield to a co-routine) using Rubinius tasks."

http://betterruby.wordpress.com/2008/03/18/shotgun-the-rubinius-virtual-machine/

So, actually, continuations are not possible yet (you can't yield from
task, or resume it) or I miss something between tasks and channels?

[Kevin Clark]

On Thu, Mar 20, 2008 at 3:35 PM, Oleg Andreev <oleg...@gmail.com> wrote:
> So, actually, continuations are not possible yet (you can't yield from
> task, or resume it) or I miss something between tasks and channels?

I'm not sure what tasks and channels have to do with continuations. I
think you're getting coroutines and continuations mixed up. A
continuation is essentially a set jump and long jump. It saves the
stack and jumps back. Rubinius can do this easily because of the full
ruby stack of MethodContexts, as far as I remember.

--
Kevin Clark
http://glu.ttono.us

[Oleg Andreev]

Oh, you're right. I know, continuations and coroutines are technically
different, but I don't see a difference in semantics. For me,
coroutines can be easily implemented with continuations (there had
been a ruby quiz solution on 1.8 illustrating this) and vice versa.
Where am I wrong?

And one more thing: how much memory consumes single MethodContext and
a stack of contexts? I'm wondering, what's the price of holding 10 000
concurrent clients (tasks/coroutines) in memory.

[agardiner]

> And one more thing: how much memory consumes single MethodContext and
> a stack of contexts? I'm wondering, what's the price of holding 10 000
> concurrent clients (tasks/coroutines) in memory.

There is no simple answer to how much memory a MethodContext consumes;
at a minimum, each context consumes storage for 19 fields (each 4-
bytes or 8-bytes, depending on whether the platform is 32-bit or 64-
bit), i.e. 76 or 152 bytes. However, a method context also holds
fields for any locals defined in the method, plus a reference to the
calling method context (which links to its caller, and so on). As
such, a single method context could indirectly result in a claim on a
large chunk of memory.

[Oleg Andreev]

Thanks a lot. I did an imaginary experiment and found out, that for a
multiuser web-application it doesn't really matter whether you keep
contexts like in a Smalltalk Seaside, or throw them away on each
request and produce same number of brand-new contexts. Average memory
footprint might be the same.
Difference occures in the edge case: when user left the site, session
is still valid for some time interval (thus, consuming a memory).
Relative memory overhead (%) for Seaside-like design equals to
session_timeout/session_duration.

So, when the average session is 10 minutes long and timeout is 5
minutes, memory usage overhead is 50%. So, actually, "seaside-design"
introduces significant overhead for short sessions.

Now I'm wondering, am I right?

[Tony]

My preferred persistence model is to concurrently render pages as components as part of the Presentation Abstraction Control (http://en.wikipedia.org/wiki/Presentation-abstraction-control) pattern, a.k.a. hierarchical MVC.  Each component can be modeled as an Actor, with a fixed lifetime where each effectively caches a bit of state which can be restored from the database.  The target would be highly interactive, desktop-like AJAX applications where a component, if it still persists, can be accessed to provide interactive state changes, but any can be recalled from database if it has expired.

--
Tony Arcieri
medioh.com

[Michael Klishin]

On 27/03/2008, Oleg Andreev <oleg...@gmail.com> wrote:
> So, when the average session is 10 minutes long and timeout is 5
> minutes, memory usage overhead is 50%. So, actually, "seaside-design"
> introduces significant overhead for short sessions.
>
> Now I'm wondering, am I right?

You may find interesting listening to old episode of Ruby on Rails
podcast with Avi Bryant. Avi says that Seaside's main drawback is high
memory footprint for most of applications.

--
MK

http://novemberain.com

[Oleg Andreev]

Nevetheless, we may use fibers/continuations for a part of the
application. For example, step-by-step interfaces (wizards) are a
headache for a classical stateless webserver design, but are perfect
for cc-based design.

[Sean Allen]

This is the same step by step scenario ( with slight branching ) that we
are looking at, I prototyped using a scheme continuation webserver
and had 1/10th the code of a stateless webserver design.

I'll buy extra ram if I get an easier to maintain and understand code
base.