Bug report
Bug description:
In GH-134747 and GH-141140, sys.thread_info.lock was changed to "pymutex". However, the implementation of _thread.Lock had already been changed to use PyMutex in Python 3.14 (fca5529), and was backported to 3.13.1 (20242a4). In Python 3.13.1 and later, _thread.RLock is the only synchronization primitive that depends on PyThread_type_lock. And in Python 3.14, _thread.RLock was also changed to use the parking-lot-based _PyRecursiveMutex (67f6e08). However, sys.thread_info.lock remained unchanged: it's still "semaphore" on Linux and None on Windows in Python 3.14.
GH-134747 only changed the implementation of PyThread_type_lock, which is irrelevant to synchronization primitives in the threading module. So changing the value of sys.thread_info.lock to "pymutex" makes its meaning ambiguous. In addition, PyMutex itself still uses platform-dependent synchronization primitives, namely POSIX semaphore, pthread_cond+pthread_mutex, and CreateSemaphore on Windows (ref: https://github.com/python/cpython/blob/main/Python/parking_lot.c), precisely the same families of primitives previously reflected by sys.thread_info.lock.
So I think the change to sys.thread_info.lock should be reverted to avoid confusing users.
cc @vstinner
CPython versions tested on:
3.15
Operating systems tested on:
Linux, Windows
Bug report
Bug description:
In GH-134747 and GH-141140,
sys.thread_info.lockwas changed to "pymutex". However, the implementation of_thread.Lockhad already been changed to use PyMutex in Python 3.14 (fca5529), and was backported to 3.13.1 (20242a4). In Python 3.13.1 and later,_thread.RLockis the only synchronization primitive that depends onPyThread_type_lock. And in Python 3.14,_thread.RLockwas also changed to use the parking-lot-based_PyRecursiveMutex(67f6e08). However,sys.thread_info.lockremained unchanged: it's still "semaphore" on Linux and None on Windows in Python 3.14.GH-134747 only changed the implementation of
PyThread_type_lock, which is irrelevant to synchronization primitives in the threading module. So changing the value ofsys.thread_info.lockto "pymutex" makes its meaning ambiguous. In addition, PyMutex itself still uses platform-dependent synchronization primitives, namely POSIX semaphore,pthread_cond+pthread_mutex, andCreateSemaphoreon Windows (ref: https://github.com/python/cpython/blob/main/Python/parking_lot.c), precisely the same families of primitives previously reflected bysys.thread_info.lock.So I think the change to
sys.thread_info.lockshould be reverted to avoid confusing users.cc @vstinner
CPython versions tested on:
3.15
Operating systems tested on:
Linux, Windows