[Python-Dev] usefulness of Python version of threading.RLock (original) (raw)

Nick Coghlan 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 we are.

Regards, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list