While working on `threading.RLock` must not support `*args, **kwargs` arguments · Issue #102029 · python/cpython · GitHub I was thinking about whether this is good idea or not. Right now I think that deprecating
threading._PyRLock is good idea indeed, here are my points.
For quite a long time
threading._PyRlock does not work as it should, see python RLock implementation unsafe with signals · Issue #57906 · python/cpython · GitHub
If a signal occurs during _Py_RLock.acquire() or release() and then operates on the same lock to acquire() or release() it, process hangs or assertions can be triggered.
This bug has existed for ages. People who want sane behaviour should just switch to Python 3. Closing.
Moreover, since Python3 we have
_thread.RLock that is used in several places of stdlib directly:
- cpython/functools.py at 7d07e5891d2843f269fac00dc8847abfe3671765 · python/cpython · GitHub
- cpython/_bootstrap.py at 7d07e5891d2843f269fac00dc8847abfe3671765 · python/cpython · GitHub
So, any other interpreters that are using CPython’s stdlib already have to adapt
_thread module. Example from
RustPython: RustPython/functools.py at 058f8c55005a8ae93275957952e20a0ae9bf6968 · RustPython/RustPython · GitHub and RustPython/_thread.py at 058f8c55005a8ae93275957952e20a0ae9bf6968 · RustPython/RustPython · GitHub (they are using
_dummy_thread for now).
And the last thing: for CPython users won’t feel anything, because
_thread module is a required module for CPython: cpython/Setup.bootstrap.in at 201440e97a3433ad7691163c4a17d4c2721fd7c6 · python/cpython · GitHub and since it is always present, regular usages of
threading.RLock won’t be changed.
The only thing that will change with new deprecation notice is direct creation of
_PyRLock (right now the stdlib does not have any usages of it). However, there are some usages of
_PyRLock in the wild, but mostly they are used to monkeypatch
_PyRLock: Sign in to GitHub · GitHub and they can easily silence the warning / ignore the missing class.
So, to sum things up, we have:
- Legacy implementation with known problems
- That almost no one uses
- With a working default substitution that people rely on
- While legacy implementation can be easily (from the technical point of view) deprecated
Are there any arguments to keep things as-is?
Are there any valid use-cases for
_PyRLock that we should continue to support?
Please, share your opinions