From: Christian Boos <cboos@...>
Date: 2002-08-23T15:51:07+09:00
Subject: RE: Bug in gc.c or misunderstanding on my part?

Hi,

> -----Original Message-----
> From: Timothy J. Wood [mailto:tjw@omnigroup.com]
> Sent: Friday, August 23, 2002 6:20 AM
> To: ruby-core@ruby-lang.org
> Subject: Bug in gc.c or misunderstanding on my part?
> 
...
>    This is called from ruby_init() and ruby_run() and the resulting 
> value is used in scanning for potential Ruby objects on the native 
> stack (which is an interesting idea).
> 

rb_gc_stack_start is not only used for that, it is also
used to delimit the height of the stack for Ruby threads:
each Ruby thread holds a copy of the C stack, from 
rb_gc_stack_start to the level it was when the last task
switching occurred, so that, when scheduled to run again, 
it can be copied back onto the real C stack (+ some longjmp
wizardry...)
That's why one cannot modifiy the value of rb_gc_stack_start once
threads are running. That's also why it is a little bit difficult
to embed threaded Ruby programs...

-- CB

>    Now, the part that confuses me are things like rb_funcall().  This 
> appears to NOT update the stack base.  So, it seems like it is invalid 
> to call rb_funcall() directly (but you could call it if Ruby calls you 
> via a Ruby->C binding).  Instead, it seems like you must always call 
> ruby_run() at the top level (which really limits the usefulness of the 
> embedding API).
> 
>    What is the intended semantic of rb_funcall()?  I don't see any 
> documentation that would lead me to believe that I can't call it 
> directly after loading a script.
> 
> -tim
> 
>