On Wed, Mar 27, 2019 at 1:23 PM Nathaniel Smith <
njs@pobox.com> wrote:
On Wed, Mar 27, 2019 at 10:44 AM Daniel Nugent <nugend@gmail.com> wrote:
>
> FWIW, the ayncio_run_encapsulated approach does not work with the transport/protocol apis because the loop needs to stay alive concurrent with the connection in order for the awaitables to all be on the same loop.
Yeah, there are two basic approaches being discussed here: using two
different loops, versus re-entering an existing loop.
asyncio_run_encapsulated is specifically for the two-loops approach.
In this version, the outer loop, and everything running on it, stop
entirely while the inner loop is running – which is exactly what
happens with any other synchronous, blocking API. Using
asyncio_run_encapsulated(aiohttp.get(...)) in Jupyter is exactly like
using requests.get(...), no better or worse.
And Yury's followup suggests that it's hard to achieve total isolation between loops, due to subprocess management and signal handling (which are global states in the OS, or at least per-thread -- the OS doesn't know about event loops).
I just had another silly idea. What if the magical decorator that can be used to create a sync version of an async def (somewhat like tworoutines) made the async version hand off control to a thread pool? Could be a tad slower, but the tenor of the discussion seems to be that performance is not that much of an issue.