Repository navigation
Add PyMutex, PyMutex_Lock, PyMutex_Unlock #142
Description
Activity
I think backporting PyMutex would be nontrivial, since it relies on integration with mimalloc AIUI.
Instead, you could follow what we did in NumPy and explicitly wrap PyThread_type_lock and PyMutex in a compatibility macro, or similar. numpy/numpy#27011
I'm not sure if it makes sense to put something like that in pythoncapi-compat.
I was hopping that it would have been possible to have a generic way to implement it here, maybe using
PyThread_type_lockinternally.But after playing for a while with your suggestion (which was also Emma's), I'm starting to wonder if it's possible at all, as
PyMutexAPI lacks the init & free methods.But my knowledge about both C and the CPython C API is limited, so I would be happy if someone proves me wrong!
In the meanwhile, I will work following the suggestion previously mentioned. Thanks!
PyMutex doesn't need to be heap-allocated, so you can leave the allocate and free functions as stubs. The docs for PyMutex say you need to initialize like it like e.g.
PyMutex mut = {0};But that's the only special thing you need to handle.
Sorry, I was not clear at all in my last message.
I was thinking if it was possible, as a compatibility layer to
PyMutex, to implementPyMutexusingPyThread_type_lockfor older versions of Python not havingPyMutex.Like you mentioned, since the initialization of
PyMutexin code that would use it does not call any function, I don't see where the call toPyThread_allocate_lockcan be hooked up in the compatibility layer.Likewise for calling
PyThread_free_lock.Couldn't the compat function just not do anything to allocate and free the object in the
PyMutexbranch that 3.13 and newer use?For example, in
NpyString_free_allocatorin NumPy, there's an ifdef so that on older python versions we free thePyThread_type_lockmutex that hangs off the allocator but on newer versions we do nothing becausePyMutexdoesn't need to be free'd.There's a similar ifdef in
NpyString_new_allocator. You can grepstatic_string.cin NumPy forPY_VERSION_HEXto find all the version-dependent code. It turns out that StringDType was the only place where we were usingPyThread_type_lockbefore we added free-threaded support and we're only usingPyMutexelsewhere in code paths that are only unsafe under the free-threaded build.Does that make sense?
PyMutexwas added to Python 3.13 and it's part of the public C API since Python 3.13. You don't need pythoncapi-compat on Python 3.13 and newer.Backporting the whole feature to Python 3.12 would be too much work (add too much code, complicated to maintain).
I suggest closing this issue. You have to add two different code paths depending on the Python version:
PyMutexfor Python 3.13 and newer, orPyThread_allocate_lock()on Python 3.12 and older.gBy the way, I'm working on python/cpython#134747 : "Change PyThread_allocate_lock() implementation to PyMutex" on Python 3.15 :-)
I understand that backporting
PyMutexfor Python 3.12 and below is not something you want to support in this repository. Instead, users should make the necessary changes in their code to use eitherPyMutexorPyThread_allocate_lockbased on the Python version.Thank you for the pointers!
Reacted by Victor Stinner and Nathan Goldbaum
Hello, I am doing a backport of code using
PyMutex/PyMutex_Lock/PyMutex_Unlock. Could it be possible to add them to this repository?References: