Yury Selivanov <yseliva...@gmail.com> added the comment:
> That's good to know and I think more convenient to work with, so +1 from me. > I guess my remaining question though is whether it's okay to `await > lock.acquire()` on a single lock instance from multiple different running > event loops (presumably each in their own separate threads) or if there's a > need to restrict it to only one event loop. No, it's not OK to use one lock across multiple loops at the same time. But most asyncio code out there doesn't have protections against that, and we never advertised that having multiple loops run in parallel is a good idea. So while we could build protections against that, I'm not sure its needed. Andrew, thoughts? > From what I've seen of asyncio user code, it seems reasonably common to > create async primitives (lock, semaphore, queue, etc.) in the __init__ for > some class prior to using the event loop, which would fail with usage of > `get_running_loop()` in the __init__ for the primitives. So, if it's not an > issue to wait until accessing the event loop until it's actually needed (e.g. > in the lock.acquire() or queue.get/put()), I think we should definitely try > to be conscious about when we call `get_running_loop()` going forward to > ensure we're not imposing arbitrary inconveniences on users. Yep. This sums up how I think of this now. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue42392> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
