Berker Peksag added the comment:
issue 25516 is a duplicate, but I'm going to close this one since issue 25516
has a patch.
--
nosy: +berker.peksag
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> threading.Condition._is_owned() is wrong when using
Antony Lee added the comment:
For the second half, the same behavior applies under Linux -- basically, a
simple Lock doesn't have a notion of owning thread and can the be unlocked by
any thread.
However, the first half is not correct if the lock used is a *RLock-like*
object (that is, it has
Changes by Mark Dickinson dicki...@gmail.com:
--
nosy: +mark.dickinson, tim.peters
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20247
___
___
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +neologix
versions: +Python 2.7, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20247
___
Tim Peters added the comment:
They certainly should _not_ be swapped, as explained clearly in the message
following the one you referenced. For the first half:
if self._lock.acquire(0):
succeeds if and only if the lock is not held by _any_ thread at the time. In
that case, the lock
New submission from Antony Lee:
I believe that the implementation of Condition._is_owned is wrong, as mentioned
here: https://mail.python.org/pipermail/python-list/2012-October/632682.html.
Specifically, the two return values (True and False) should be inverted.
I guess this slipped through
