[Python-Dev] usefulness of Python version of threading.RLock
ncoghlan at gmail.com
Sat Jan 7 16:38:26 CET 2012
2012/1/8 Matt Joiner <anacrolix at gmail.com>:
> Nick did you mean to say "wrap python code around a reentrant lock to create
> a non-reentrant lock"? Isn't that what PyRLock is doing?
Actually, I should have said recursive, not reentrant.
> FWIW having now read issues 13697 and 13550, I'm +1 for dropping Python
> RLock, and all the logging machinery in threading.
While I agree on removing the unused and potentially problematic
debugging machinery, I'm not convinced of the benefits of removing the
pure Python RLock implementation. To quote Charles-François from the
tracker issue: "Now, the fun part: this affects not only RLock, but
every Python code performing "atomic" actions: condition variables,
barriers, etc. There are some constraints on what can be done from a
signal handler, and it should probably be documented."
Remove the pure Python RLock doesn't seem to actually solve anything -
it just pushes the problem of fixing the signal interaction back onto
third party users that are even more ill-equipped to resolve it than
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev