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 14:05:52 GMT
On 06/30/2011 02:03 PM, Darryl L. Pierce wrote:
> On Thu, Jun 30, 2011 at 11:55:03AM +0100, Alan Conway wrote:
>> 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.
>
> That's very true. In thinking this through, it seems that a blocking
> calling is going to inevitably block the Ruby<  1.9 main thread.
>
> Is there a mechanism in place now where the broker can send a notice to
> a client after an asynchronous process completes to say it's done?
>

There is in the AMPQ protocol and under the covers of the C++ client but I don't 
think it's exposed in the new API other than by waiting for a blocking call to 
complete. There's a larger concurrency theme that needs to be addressed which 
includes async responses, thread dispatching models (for async responses and 
message delivery) and event loop integration.

I'd like to see something like:

- a thread safe "get next event" call that returns events for message delivery, 
async responses and any other triggers coming from the broker
- a file descriptor that is readable whenever there are qpid events pending so 
you can knit this into a poll/epoll/select loop
- an ease-of-use layer that provides ready-made thread pool implementations of 
common dispatch policies e.g. message listeners, thread-per-connection, 
thread-per-session, thread-per-message etc.

The ruby integration would use the lower level event handling API to dispatch 
qpid events in ruby threads in whatever way is appropriate and avoid blocking 
calls entirely.  Obviously we're not there yet but I think we will eventually 
move in that direction.

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


Mime
View raw message