Nick Davies <pyt...@nicolasdavies.com.au> added the comment:
My preference would actually be number 3 because: 1: I agree that this isn't really a safe option because it could slow things down (possibly a lot) 2: I haven't found this to be rare in my situation but I am not sure how common my setup is. We have a threaded server with a mix of sync and asyncio so we use run in a bunch of places inside threads. Any time the server gets busy any task creation that occurs during the return of run crashes. My two main reservations about this approach are: - There is a potentially unbounded number of times that this could need to retry. - Also this is covering up a thread unsafe operation and we are pretty lucky based on the current implementation that it explodes in a consistent and sane way that we can catch and retry. 3: Loop is already expected to be hashable in 3.7 as far as I can tell (https://github.com/python/cpython/blob/3.7/Lib/asyncio/tasks.py#L822) so other than the slightly higher complexity this feels like the cleanest solution. > The fix can be applied to 3.7 and 3.8 only, sorry. Python 3.6 is in security > mode now. Thats fine, you can work around the issue using asyncio.set_task_factory to something that tracks the tasks per loop with some care. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36607> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com