[Async-sig] Inadvertent layering of synchronous code as frameworks adopt asyncio

[Guido van Rossum]

On Mon, Mar 25, 2019 at 5:11 PM Ben Darnell <ben at bendarnell.com> wrote:

> On Mon, Mar 25, 2019 at 8:02 PM Guido van Rossum <guido at python.org> wrote:
>
>>
>> Given PBP, I wonder if we should just relent and have a configurable flag
>> (off by default) to allow nested loop invocations (both the same loop and a
>> different loop).
>>
>>
> Allowing reentrant calls to the same loop is not a good idea IMO. At best,
> you'll need to carefully ensure that the event loop and task
> implementations are themselves reentrancy-safe (including the C
> accelerators and third parties like uvloop?), and then it just invites
> subtle issues in the applications built on top of it. I don't think there's
> a good reason to allow or support this (and nest_asyncio should be heavily
> discouraged). I do, however, think that PBP is a good enough reason to
> allow opt-in use of multiple event loops nested inside each other (maybe
> something on the EventLoopPolicy for configuration?).
>

Well, at least I am not alone in being very wary about nest_asyncio (and
disappointed that Jupyter recommends it).

It would certainly require carefully ensuring reentrancy of the asyncio
implementation. I guess that's one reason why nest_asyncio disables the C
accelerators and doesn't work with uvloop. Regarding reentrancy of
applications, I think that would be somewhat limited -- the critical
section I showed in my first message in this thread would still be safe, as
long as the queue implementation chooses not to call out to code that uses
run_until_complete(). We might need a convention to document whether
something runs an event loop (in the strict asyncio philosophy this
convention is `async def` of course :-).

I guess calling out to a different event loop is no worse than calling out
to requests -- I consider both strong violations of asyncio's ideals.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20190325/feb02c38/attachment-0001.html>