From: Bill Kelly <billk@...>
Date: 2010-02-07T09:03:14+09:00
Subject: Re: embedding ruby

Josep Pujol wrote:
> 
> Bill Kelly wrote:
>> We embed ruby 1.8.x in a C++ app on Windows / OS X.
>>
>> In our case, we run Ruby in a separate thread.  Only trick was that
>> the stack size of threads other than the main thread may be small by
>> default.  And we use boost threads.  So I had to modify boost to
>> create the thread with a large enough stack:
>
> I plan to use ruby in several threads (it's a gui application and
> each menu can trigger some ruby code). Is it safe enough to use
> a mutex or I must initialize something (the stack?) for each
> thread?

Well again, my experience is only embedding MRI Ruby 1.8.x.  In this
case, the ruby interpreter itself runs in a single thread.

So on the Ruby side, all Ruby-threads are green threads running in
the single native Ruby thread.

We do indeed use Ruby threads to create GUI elements.  And in the
reverse direction we do forward GUI events from the C++ GUI event
thread back to Ruby.

What we never do is allow arbitrary C++ threads to call directly
into Ruby.

So in a situation where C++ makes a call like this:

  ruby_context.eval("GUI.forward_event(:click,"+control_id+")");

This 'eval' doesn't call ruby directly, but queues the command and
waits for the Ruby native thread to process the command.

So there is indeed a mutex (and a condition variable) involved here,
but its purpose is to implement the queuing mechanism between C++
threads and the Ruby interpreter thread.



For what it's worth, in the latest app I'm developing, I've changed
this so that Ruby runs in an entirely separate process.  And the C++
part of th app just acts like a "window server", which the Ruby
process connects to, and uses to create the GUI.


Regards,

Bill