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:55:03 GMT
On 06/29/2011 07:43 PM, Darryl L. Pierce wrote:
> On Wed, Jun 29, 2011 at 04:58:36PM +0100, Gordon Sim wrote:
>>> 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...
> I agree. I put that out that as one possible path, but it's too easily a
> vector for Ruby-specific problems.
>>> 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.
> What do you mean by "supports non-blocking usage more effectively"? What
> I would like to do, and what is more Ruby-ish, would be to call the
> non-blocking version but provide a lambda function that can be called.
> A more Ruby-like way would be to have Ruby _not_ pass :block =>  true to
> the underlying implementation and, instead, require the user pass in a
> lambda function. Then the API could spawn a Ruby thread, do the sync,
> and then call the lambda function after it completes. So we never
> _actually_ block the thread while the call runs. But we give the user a
> means for knowing when the call finishes (which is what I assume is the
> goal of the synchronous call since it returns no value).

That is the right idea, but how do you wait for the underlying non-blocking 
operation to complete? We need to add callbacks or futures to the C++ 
non-blocking operations to do this. But a C++ callback may be called in a 
non-ruby thread, I don't know what facilities ruby has to resolve that. A future 
just moves the problem - when you call   future.wait() you'll block ruby again.

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

View raw message