You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by "Darryl L. Pierce" <dp...@redhat.com> on 2011/06/27 20:16:49 UTC

Threading issues with Ruby < 1.9...

I spent a good chunk of today examining the issues around trying to
spawn a thread within Ruby to handle blocking calls, such as
Session.sync. The goal was to avoid having the main application thread
in Ruby block while the synchronous operation occurs.

It turns out that there are some limitations to thread handling within
Ruby. Specifically, in Ruby 1.8 we cannot spawn a thread to handle
making a call to the extension while the main thread continues; i.e.,
calling a blocking I/O operation in a separate thread will still block
the main thread.

This is mainly due to Ruby's threading model not using native threads.
In Ruby 1.9 we'll have pthreads, but that doesn't help us now.

So the question becomes: for Ruby 1.8, is it better to go to C++ and
extend the Session class (for example) to provide native threads, or do
we just inform the user that a blocking operation like that will stop
the main thread?

In the former case we could have a child class that checks the block
argument and, if true, spawns a native thread. It would require a
pointer to a Proc as well so that it has a callback to notify when the
call completes.

Thoughts? Suggestions?

-- 
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/