is the ruby interpreter stackless?

[zuzu]

ok, i think i've got a handle on the continuations/coroutine/closures concept.
reading http://mojave.caltech.edu/papers/cont-tut.ps it would seem
actually quite easy (to the point where i'm surprised so many people
can explain it so poorly that quite a brouhaha exists around it).

but now, the issue seems low-level. does the ruby interpreter bother
using a stack? (my guess would be no, given garbage collection and
built-in closures.)
is 'return' simply an alias for "calling the caller"? (and thus
'yield' an alias for calling the anonymous (lambda) closure passed in
as a "special" (syntactally) argument?)

peace,
-z

 

[Lennon Day-Reynolds]

Ruby uses the C stack; its continuations are implemented using
setjmp/longjmp. That makes the Ruby API very natural to use from C,
but unfortunately, also means that the stack limits of the native
platform apply, and that Ruby's continuations are no faster than full
native SMP threads.

 

[Robert Klemme]

Ruby uses the C stack; its continuations are implemented using
setjmp/longjmp. That makes the Ruby API very natural to use from C,
but unfortunately, also means that the stack limits of the native
platform apply, and that Ruby's continuations are no faster than full
native SMP threads.

Is that really the case? I mean, this doesn't look like "natural" stack
depth limit:

$ ruby -e 'def foo() foo end; begin; foo; rescue Exception => e; puts
e.backtrace.size; end'
13633

Or does each single call use up so much stack space? I did a simple
recursive function in C and it didn't core prior to level 129536. So
basically that would mean that Ruby uses 10 times the stack space per
invocation.

Kind regards

robert

 

[Ara.T.Howard]

Or does each single call use up so much stack space? I did a simple
recursive function in C and it didn't core prior to level 129536. So
basically that would mean that Ruby uses 10 times the stack space per
invocation.

if that is true - it's quite an important observation:


def alot_faster
<snip 10000 lines>
end


def not_so_fast
not_so_fast_0
not_so_fast_1
not_so_fast_2
not_so_fast_3
end
def not_so_fast_0
<snip 2500 lines>
end
def not_so_fast_1
<snip 2500 lines>
end
def not_so_fast_2
<snip 2500 lines>
end
def not_so_fast_3
<snip 2500 lines>
end

always true - but perhaps in ruby __particularly__ true. an argument for a
preprocessor?

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================

 

[Lothar Scholz]

Hello Robert,



RK> Is that really the case? I mean, this doesn't look like "natural" stack
RK> depth limit:

RK> $ ruby -e 'def foo() foo end; begin; foo; rescue Exception => e; puts
RK> e.backtrace.size; end'
RK> 13633

Please look at "eval.c" it is not difficult to understand and much
better then guessing and writing naive tests.