My intention is to support a variety of scenarios for I/O. I believe it is
a key requirement that we can create sockets/fds in either python or C and
regardless of where they are created, they need to be serviceable by a
single I/O loop written either buy us or by others in C or in pure python.
(I think that covers all the bases, but if I'm missing a key combination,
then let me know.)

I believe the implementation is almost able to support all these scenarios
now, modulo a few details here and there. I will post some code snippets of
all the different permutations fairly soon (probably tomorrow as I am off


On Fri, Jan 16, 2015 at 4:49 AM, Gordon Sim <> wrote:

> On 01/16/2015 08:06 AM, Flavio Percoco wrote:
>> One thing that I did want to mention (and forgot, obviously) is that
>> for things like non-blocking IO, we want to make sure the API works
>> well not just with eventlet but also with asyncio[0].
>> Also, it'd be worth taking a look at how the Twisted[1] api works since
>> it's a long-time python project with an event based API like the one
>> you guys are building for proton.
> Yes, I very much agree on both points. There is a JIRA (with a patch
> attached I believe) for python 3 support, and once that is in then figuring
> out how it would work well with asyncio is one of the things I've had in
> mind. Likewise with twisted.
> I knocked a couple of quick examples using the tornado event loop. There
> is still some work there though to better control the write interest in
> AMQP sockets, when that is triggered by non-AMQP events.
>  Hope this helps,
>> Flavio
>> [0]
>> [1]

Reply via email to