STINNER Victor added the comment: Guido> So in order to do correct diagnostics here we would have to add an "owning thread" pointer to every event loop;
I didn't understand why this approach was not taken when the check was introduced. I was surprised that get_event_loop() was used for the check instead. Here is a patch checking the thread using threading.get_ident(). The check still works when set_event_loop(None) is used in unit tests. I created the issue #23074 for the change: get_event_loop() must always raise an exception, even when assertions are disabled by -O. -- asyncio requires thread support, it is already the case without my patch. For example, the event loop policy uses threading.Local. In the aioeventlet project, call_soon() writes a byte in the self pipe (to wake up the selector) if the selector is waiting for events; call_soon() is "green thread safe". It is less efficient than calling forcing users to call explicitly call_soon_threadsafe(), but aioeventlet is written to be compatible with asyncio and eventlet, while these projects are very different. In the aiogevent and aioeventlet projects, I also store the current greenlet, but for a different purpose: ensure that yield_future() is not called in the greenlet running the event loop, which would blocking. ---------- Added file: http://bugs.python.org/file37483/check_thread.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22926> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com