Irit Katriel added the comment:
The RLock documentation is a bit more verbose than it needs to be (for
instance, there is no reason to specify the "no args" case separately from the
"blocking=True" case (since True is the default value of blocking).
The issue of balancing acquire/release cal
ahxxm added the comment:
As seen from commit log, all return type are double back-quoted, this could be
a rendering error.
I think this commit somehow makes it clear that RLock is a thread-level
reentrant lock, some code example of suggested usage might be helpful though.
--
hgrepos:
Josh Rosenberg added the comment:
Per the docs ( https://docs.python.org/3/library/threading.html#rlock-objects ):
"To unlock the lock, a thread calls its release() method. acquire()/release()
call pairs may be nested; only the final release() (the release() of the
outermost pair) resets the l
New submission from Mateusz:
The number of acquisitions must be the same as the number of releases or else
lock will not be released for other threads leading to deadlock. This is not
mentioned in documentation.
First acquisition returns boolean and further acquisitions return 1. This is
als
