[issue26969] ascynio should provide a policy to address pass-loop-everywhere problem

Ilya Kulakov report at bugs.python.org
Fri May 6 15:58:12 EDT 2016


Ilya Kulakov added the comment:

> Why does it have to be a standard part of asyncio?

I've only seen few libraries that deal with asyncio so far (aiohttp, pyzmq), but my general impression is that this is a generic problem.

With asyncio code should be (ideally) written as a set of coroutines which schedule each other or are called in response to monitored events. That means (and asyncio very implementation shows that) loop has to be "self" for all coroutines it executes.

Thread-local default event loop is a good solution to get an entry point into the event loop from an out-of-event-loop execution location. But (ideally) there will be exactly one place in code where this behavior is convenient: when you "instantiate" and run event loop. After that the event loop becomes "self" for each coroutine it may run and therefore it's now convenient for get_event_loop to return currently running event loop.

Probably it would make sense to modify behavior of the default policy to make get_event_loop to return Thread-local event loop when called from out-of-event-loop and return currently running event loop when called from within a coroutine.

> Why don't you just use 'loop = asyncio.get_event_loop()' in places where you need the loop?

As David pointed out, I'm not using thread-local event loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________


More information about the Python-bugs-list mailing list