Currently, trio-asyncio doesn't install async generator hooks, so asyncio tasks get Trio's hooks, which try to close asyncio's async generators in Trio context. We should install our own hooks which delegate to Trio's hooks or asyncio's hooks depending on the context in which the async generator was first iterated.
The tricky part here is figuring out from finalizer whether an async generator belongs to trio-asyncio, and if so, to which loop. Trio has a similar problem when distinguishing Trio asyncgens from asyncio ones when running as a guest of asyncio. We can solve it in the same way Trio does: set a magic local in the async generator's f_locals, with a name like @trio_asyncio_loop_owner whose value is the trio-asyncio event loop that should be responsible for finalizing this generator.
Probably we should fix this in concert with #91, using the same teardown sequence that Trio uses: stop all asyncio tasks, prevent new tasks from starting, then close outstanding async generators.
Currently, trio-asyncio doesn't install async generator hooks, so asyncio tasks get Trio's hooks, which try to close asyncio's async generators in Trio context. We should install our own hooks which delegate to Trio's hooks or asyncio's hooks depending on the context in which the async generator was first iterated.
The tricky part here is figuring out from
finalizerwhether an async generator belongs to trio-asyncio, and if so, to which loop. Trio has a similar problem when distinguishing Trio asyncgens from asyncio ones when running as a guest of asyncio. We can solve it in the same way Trio does: set a magic local in the async generator'sf_locals, with a name like@trio_asyncio_loop_ownerwhose value is the trio-asyncio event loop that should be responsible for finalizing this generator.Probably we should fix this in concert with #91, using the same teardown sequence that Trio uses: stop all asyncio tasks, prevent new tasks from starting, then close outstanding async generators.