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:
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/9da7ff868f1405893947118178d62bb7e1eb3...
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__.