[rabbitmq-discuss] Pika question

Gavin M. Roy gmr at myyearbook.com
Tue Sep 14 03:39:31 BST 2010


I've been working on a native adapter for Pika for use with Tornado which
has gotten some attention on the Tornado list. I've been focused on trying
to implement a non-hacky adapter as other attempts are focused on either
moving away from stock Tornado (gTornado, Twisted implementations, etc) or
patching both Pika and Tornado.

In working through the process of implementation, I became focused on the
drain_events() function which is to be extended/implemented by the client.
 Basically, as I understand it, drain_events() is meant to be the blocking,
time based loop that allows Pika to let other things go on in the async
engine while it is not doing anything.  With asyncore this methodology works
because you can loop against it in a pseudo blocking fashion.
 Unfortunately, Tornado, as far as I can tell, does not have a similar loop
functionality.

In digging deeper I found the main purpose of this function is to block on
pika.connection.Connection._rpc() which in many cases is called without
regard to the response, but in others the response is part of the protocol
negotiation. I have some reservations about thinking of Pika as a truly
async library because of its dependence on the blocking behavior of
Connection._rpc().  As you can see, Connection._rpc() ends with
channel.wait_for_reply (
http://github.com/tonyg/pika/blob/master/pika/connection.py#L326) which on
line 124 (http://github.com/tonyg/pika/blob/master/pika/connection.py#L323)
calls up to the drain_events() function, waiting for the channel to have a
stack of replies to process.

I've been thinking about what it would take to make _rpc() an actual async
function where you register the call with a callback and then move on.
Obviously Tony G knows the code the best, but are there any other opinions
about how this should be done?

Tony, if I refractor this to work in a non-blocking way, would you be
interested in having it upstream?  Would anyone be interested in helping?

Regards,

Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100913/41f84e31/attachment.htm>


More information about the rabbitmq-discuss mailing list