Is the ruby interpreter stackless?

ruby-talk
1

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

2

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.

···

--
Lennon
rcoder.net

3

"Lennon Day-Reynolds" <rcoder@gmail.com> schrieb im Newsbeitrag
news:5d4c6124040824184528f7801c@mail.gmail.com...

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

4

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

···

On Thu, 26 Aug 2004, Robert Klemme wrote:

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.

--

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

===============================================================================

5

Hello Robert,

"Lennon Day-Reynolds" <rcoder@gmail.com> schrieb im Newsbeitrag
news:5d4c6124040824184528f7801c@mail.gmail.com...

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

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

···

--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's