Re: ruby_init() and C call stack in Ruby 1.9

Nobuyoshi Nakada wrote:
>> Suraj N. Kurapati wrote in [ruby-core:16432]:
>>> Yukihiro Matsumoto wrote:
>>>> No Ruby object should be referred from stack region lower than the
>>>> position at the time of ruby_init() invocation.
>>>
>>> For Ruby 1.8, I was able to guarantee this assumption by only using
>>> Ruby's C API inside a POSIX thread:  the thread preserves the C call
>>> stack for the life of the Ruby interpreter.
>>>
>>> However, for Ruby 1.9, it is not possible to invoke ruby_init()
>>> inside a POSIX thread (as both you and Nobu have explained in
>>> ruby-core:15759 and ruby-core:15760).
>>>
>>> Therefore, how can I guarantee this assumption for Ruby 1.9?
> 
> Why can't you call ruby_sysinit() and ruby_init() in the maint
> thread?

Good question.  Allow me to explain my use case:

I invoke a Verilog simulator by specifying the path to my shared
object file.  The simulator loads my shared object file and
immediately it invokes a predefined function.  (Note that the
simulator is the main thread.)

Inside this function, I call ruby_init() and then register (with the
simulator) a callback function that must be executed at the start of
the simulation.

After this function returns, the simulator does some other
initialization and then prepares to begin the simulation.

Since I registered a start-of-simulation callback, the simulator
first invokes my callback function (from a *different* C call stack
position in a lower region of memory than the invocation of the
predefined function) before really beginning the simulation.

As a result, any usage of Ruby's C API inside my callback function
causes a segmentation fault.  This is because Ruby was initialized
in one stack region, but now the Ruby C API is being used in a lower
stack region.

For this reason, I am very interested in shielding Ruby from the
main thread's inconsistent C call stack by running Ruby inside a
pthread.  The pthread preserves (for the life of the Ruby
interpreter) the C call stack where ruby_init() was called.

For example, here is some pseudocode describing this technique:

void* the_ruby_protector(void* dummy)
{
   ruby_init();

   // wait for start-of-simulation callback
   protector_is_done();  // wake up wait_for_protector() callers
   wait_for_simulator();

   // use the Ruby C API
   rb_funcall( ... );
   rb_const_get( ... );
}

void the_predefined_function()
{
   pthread_create( ... the_ruby_protector ...);

   // wait until protector is finished initializing Ruby
   wait_for_protector();
}

void the_callback_function()
{
   // resume the protector (allow it to continue executing)
   simulator_is_done();  // wake up wait_for_simulator() callers
   wait_for_protector();
}

The wait_for() and is_done() functions are just wrappers around
pthread_mutex synchronization primitives.  They allow one thread to
be running at a time.

>> I really wish Ruby's C API was like OpenGL: a state machine.
>> It doesn't matter from what stack position you query/modify the
>> machine  state.
> 
> OpenGL has its own GC?

Excellent point.  However, it could theoretically have its own GC
and hide that fact from a user by malloc()ing its own stack region
instead of relying on the C call stack position during init.  :-)