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>