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/
pgpuKn5Qs8VR7.pgp
Description: PGP signature
