This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yselivanov
Recipients aeros, asvetlov, yselivanov
Date 2020-11-18.01:43:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1605663822.12.0.769977414601.issue42392@roundup.psfhosted.org>
In-reply-to
Content
> 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.
History
Date User Action Args
2020-11-18 01:43:42yselivanovsetrecipients: + yselivanov, asvetlov, aeros
2020-11-18 01:43:42yselivanovsetmessageid: <1605663822.12.0.769977414601.issue42392@roundup.psfhosted.org>
2020-11-18 01:43:42yselivanovlinkissue42392 messages
2020-11-18 01:43:41yselivanovcreate