On 06/29/2011 02:06 PM, Darryl L. Pierce wrote:
In working on the Ruby layer I've hit a serious road block.For any call that blocks on I/O (Session.synch :block => true) the Ruby bindings can _not_ wrap that call in a Ruby thread and have it run while the main application thread continues to run. So, even though we do this: def sync(args = {},&callback) block = args[:block] || false if block # Spawn a thread to run the sync Thread.new do @session_impl.sync true callback.call if callback end else @sessimpl_impl.sync false callback.call if callback end end the call to Session.sync will still block the whole application until the call completes. In Ruby 1.9 we'll have other options to work with this since pthreads will be available in the code. But, for now, we won't be able to use _Ruby_ threads to work around this limitation. So in thinking htis over, I see one of two paths to go down: 1. Create a C++ child class of Session (and other classes that have blocking I/O) and, when a blocking call is made, wrap the call in a native thread. Then have the native code invoke the lamda funtion, and make that lamda a requirement for such a call.
I'm not too keen on this, it seems at best a short term fix...
2. Inform the developer that blocking calls will stop the application until Ruby 1.9. Thoughts?
...another approach is to ensure that the API being SWIGed supports non-blocking usage effectively. Though that will take more effort it seems a nicer solution long term.
I would certainly like to enhance the c++ messaging API in this way. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
