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:[email protected]