Nick Davies <[email protected]> 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 <[email protected]>
<https://bugs.python.org/issue36607>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
