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 a notion of ownership, and once acquired it can be reacquired and released only by the owning thread). If that is the case, then _lock.acquire(0) will succeed if the current thread already owns the lock (or if no one owns it) and fail if the lock is owned by another thread. So perhaps it may not be possible to do really better, but the docs could (should?) mention that custom implementations of locks passed to Condition objects should implement their own version of _is_owned. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20247> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
