[Async-sig] asyncio <-> twisted interoperability

[Yury Selivanov]

[..]
> Actually, +1 for Ben’s suggestion to revisit if asyncio.Futures really need call_soon scheduling of callbacks. Specifically, a torrent of call_soon doesn’t really achieve “fair scheduling” as suggested by Yury anyway:
> 
> https://gist.github.com/ambv/3324e3e569b9f7883dfcb9c8cb1d5445

One quick story about call_soon: while working on uvloop I once spent a couple of hours debugging why asyncio/sslproto.py didn’t work.  Turned out that SSLProtocol, in its connection_made scheduled some callbacks with loop.call_soon; and data_received did that too.  Turned out that libuv called data_received one loop iteration earlier, which resulted in a race condition.  What I’m trying to say here, is that making a subtle difference in how callbacks are scheduled can introduce some hard to debug bugs.

In fact, I’m thinking now that Tornado/Twisted should keep their callbacks scheduling logic as is, and asyncio should keep its current implementation.


Anyways, I’ve tried to update asyncio Future to call callbacks directly:
https://github.com/1st1/asyncio/commit/9da7ff868f1405893947118178d62bb7e1eb3a51

The result is many broken unittests, until... a segfault in test_create_ssl_connection: https://gist.github.com/1st1/797dd12932bba7b353038fb7a80148ac (I’ll investigate this later).

I’d be -1 to change callbacks scheduling in 3.5, IMO this has to wait until 3.6 even if we decide this should be done.

[..]
> +1 for replacing isinstance checks with an attribute that Twisted can add to Deferreds.
> +1 for Ben’s suggestion that we should avoid ‘asyncio’ in the name here. __isfuture__?

Yes, an asyncio-agnostic name would be better.  I like __isfuture__.


Yury