[issue26608] RLock undocumented behavior in case of multiple acquire

2021-06-18 Thread Irit Katriel
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

[issue26608] RLock undocumented behavior in case of multiple acquire

2016-07-11 Thread ahxxm
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:

[issue26608] RLock undocumented behavior in case of multiple acquire

2016-03-22 Thread Josh Rosenberg
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

[issue26608] RLock undocumented behavior in case of multiple acquire

2016-03-22 Thread Mateusz
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