STINNER Victor added the comment: Ok, here is an updated patch (version 2):
- tests still ensure that the event loop is passed explicitly - call_soon() & cie now fail if the policy has no event loop set for the current thread (before it only failed if the event loop set in the policy was different than the called event loop) > I'm not sure that this particular change is a great idea. I kind of liked > that unittests ensure that loop is passed everywhere explicitly in asyncio. I agree, but we can just monkey-patch the _assert_is_current_event_loop() to disable the check even if debug mode. For example, it can be done in test_utils.TestCase.set_event_loop(), no need to modify individual test cases. > Maybe only in debug mode? Oh sorry, I forgot to mention that my patch only enhance an existing test, _assert_is_current_event_loop(), which is only done in debug mode. I'm so happy to have this debug mode, at the beginning Guido didn't want it :-D > - modify BaseEventLoop._assert_is_current_event_loop() to fail if the thread > has an event loop Oops, the method already fails if the event loop is different than the current event loop of the policy. My patch changes the behaviour when the policy has *no* current event loop. > In your patch, you should also replace 'except AsserionError' with 'except > RuntimeError'. Ok, that's why we must reject any patch without unit test :-D > I still think you shouldn't set the thread when the loop is created but only when run*() is active. (Using call_later() from another thread when the loop is inactive should not be an error IMO -- there's nothing against passing a selector instance to another thread as long as only one thread at a time waits for it.) Hum, I'm not fully convinced. Technically, it "works" to call call_soon() instead of call_soon_threadsafe() when the event loop is not running yet. But multithreading means race condition. It probably means that in most cases, calling call_soon() would work because the event loop didn't start yet, but in some cases, the event loop may already run depending on the timing. I prefer to force users to always use call_soon_threadsafe() to avoid bad suprises. ---------- Added file: http://bugs.python.org/file37364/asyncio_thread-2.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
