-
-
Notifications
You must be signed in to change notification settings - Fork 32k
The new multiprocessing.[R]Lock.locked()
method fails.
#132561
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I am wondering if the |
Oups, this was mine commit :) |
…32586) Co-authored-by: Peter Bierma <[email protected]>
This broke the FreeBSD 14 buildbot, @YvesDup: https://buildbot.python.org/#/builders/1232/builds/5366 |
It should be fixed by #132842 but I missed the rlock test :-( I wrote #132846 to skip also the rlock test. |
FreeBSD buildbots are back to green. I close the issue. |
Bug report
Bug description:
Maybe I didn't quite understand what this feature did, but I think there's a bug when using the
locked()
method with amultiprocessing.[R]Lock
.Here is an example:
output is:
In the
locked
method, the call toself._semlock._count() != 0
is not appropriate. The internalcount
attribute is really used withmultiprocessing.RLock
to count number of reentrant calls toacquire
for the current thread.With
multiprocessing.Lock
, thiscount
is set to 1 when the lock is acquired (only once).Whatever, only other threads can obtain this value, but not other processes sharing the
[R]Lock
.IMO the test should be replace with
self._semlock._is_zero()
and the example above should also be add as unit test.Linked issue/PR
AcquirerProxy
object has no attributelocked
#115942locked
to several multiprocessing locks #115944CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS
Linked PRs
multiprocessing.SemLock.locked
method #132586The text was updated successfully, but these errors were encountered: