[Python-Dev] usefulness of Python version of threading.RLock

[Nick Coghlan]

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