I&#39;ve been working on a native adapter for Pika for use with Tornado which has gotten some attention on the Tornado list. I&#39;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.<div>

<br></div><div>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.<div>

<br></div><div>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 (<a href="http://github.com/tonyg/pika/blob/master/pika/connection.py#L326">http://github.com/tonyg/pika/blob/master/pika/connection.py#L326</a>) which on line 124 (<a href="http://github.com/tonyg/pika/blob/master/pika/connection.py#L323">http://github.com/tonyg/pika/blob/master/pika/connection.py#L323</a>) calls up to the drain_events() function, waiting for the channel to have a stack of replies to process.</div>

<div><br></div><div>I&#39;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?</div>

<div><br></div><div>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?</div><div><br></div><div>Regards,</div><div><br></div><div>

Gavin</div><div><div><div><br></div><div><br></div></div></div></div>