On Sat, Dec 12, 2009 at 7:26 AM, v01d <phreakuencies@gmail.com> wrote:

> Hi,
> I'm a little interested in a possible future where Ruby could be used
> for heavy processing stuff (but by means of calling computationally
> heavy C code, and take advantage of multi-core processors by doing
> several of these calls in parallel native threads) and I just found
> out about Ruby's "rb_thread_blocking_region" C call.
>
> What came to my mind is that maybe FFI could be used here to make
> writing these type of parallelized Ruby extensions easier, by just
> doing something like:
>
> module RubyAPI
>  extend FFI::Library
>  attach_function :rb_thread_blocking_region,
> [ :pointer, :pointer, :pointer ], :void
> end
>
> then maybe I'm wrapping a HeavyComputationLibrary:
>
> module HeavyComputationLibrary
>  extend FFI::Library
>  attach_function :long_running_computation, [ :pointer ], :value
>  attach_function :unblock_computation, [ :pointer ], :void
> end
>
> and then do something like:
> RubyAPI.rb_thread_blocking_region
> (HeavyComputationLibrary.long_running_computation, data_ptr,
> HeavyComputationLibrary.unblock_computation)

I'm not sure this is possible. You can't call into any of the Ruby VM
functions without the GIL, so even executing the ruby/ffi code to
invoke your HeavyComputationLibrary can cause issues.

  Aman

>
> Obviously there are a couple of non-existing things here (like passing
> the function pointer of a C function (maybe there's already a way to
> do that?), usage of :value), but I wanted to ask if this is feasible
> or not.
> I think that something like this could ease writing parallel-aware
> Ruby extensions (maybe with some help of Ruby Inline) for existing C
> libraries. Then again, I may be wrong.
>
> Matt
>
> PS: I'm obviously talking about Ruby 1.9 and the function call defined
> here: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/10252
>
>