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.
Not sure I follow here: if the call is blocking you _want_ the calling thread to
be blocked till the call completes so what is wrong with:
def sync(args = {})
block = args[:block] || false
@session_impl.sync block
Of course that doesn't allow you to have a callback invoked in non-blocking mode
but C++ and python APIs don't currently support this either. When the underlying
swigged API is improved to allow callbacks or futures for sync=false calls then
that can be exposed in ruby.
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 this 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 would prefer to see the underlying API improved to provide callbacks or
futures for non-blocking calls.
Then a blocking call could be implemented as a non-blocking call to C++, plus
ruby code to wait for the response without blocking the whole app. Not sure
if/how the waiting and notification will work between pthreads in the C++ layer
and ruby threads however.
2. Inform the developer that blocking calls will stop the application
until Ruby 1.9.
Isn't that already the case with any blocking IO operation? So its something
ruby developers are already living with.
Agreed it is not a good thing but I think it's going to be difficult to solve
this in Ruby until it is better solved in the underlying API and/or ruby gets
pthreads.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
