Closed smurfix closed 6 years ago
TODO: incorporate that into trio-asyncio
and check whether the tests still work, esp. those related to cancellation semantics.
… they don't, of course. This may or may not actually affect real-world code, so I'll include it, but it obviously can't be the default.
The tests probably don't pass because the shim doesn't do things like set current_task etc which some libs rely on.
I also never tested it on anything more complex than a very basic sleep.
@Fuyukai It doesn't need to, run_future
already does that (by delegating execution to asyncio).
Lots of tests pass, and one doesn't need to keep track all those fiddly wrappers …
When I tried aiohttp, it was complaining that there was no task context or something.
Yeah, aiohttp is demanding about its perceived lack of task context. I've hit that problem last month (i.e. without your wrapper ;-) but no time yet to investigate further – besides, I'd rather spend time working on a real http solution for trio anyway.
I believe that aiohttp depends on being able to do current_task().cancel()
to implement timeouts (via the async-timeout package).
(and obviously this doesn't work if we're actually in a trio task and haven't switched into an asyncio task.)
Simple version added. Complicated cases still require distinct modes.
Interposition code, thanks to @Fuyukai and slightly embellished:
Benchmarking shows an additional 10% slow-down for asyncio and no measurable change for trio, which is OK with me.