qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Synchronous I/O in Ruby client...
Date Thu, 30 Jun 2011 10:38:26 GMT
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 

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message