enhance docs for critical sections #137334
Conversation
| :class:`list` and :class:`dict` because their public C-APIs | ||
| already use critical sections internally, with the notable | ||
| exception of :c:func:`PyDict_Next`, which requires critical section | ||
| to be acquired externally. |
There was a problem hiding this comment.
I'm not sure if I agree here. Unless I've done something wrong in NumPy. I handled this for lists using the PySequence API. I take a critical section on a list, convert to a sequence using PySequence_Fast, and then operate on the sequence under a critical section. The sequence APIs also bypass the internal critical sections and they're documented not to be thread-safe, so I think this is actually the only safe way to use PySequence_Fast correctly on the free-threaded build.
| * Calling :c:func:`PyEval_SaveThread` to detach the current thread. | ||
| * Recursively entering the critical section for the same object. |
There was a problem hiding this comment.
In 3.14, don't recursive critical sections not get suspended?
There was a problem hiding this comment.
it isn't exactly recursive, there is one more condition which is that the critical section should be the topmost held critical section otherwise it can still get suspended
| * Calling :c:func:`PyEval_SaveThread` to detach the current thread. | ||
| * Recursively entering the critical section for the same object. | ||
There was a problem hiding this comment.
It may be worth mentioning that these are exactly the same guarantees provided by the GIL.
📚 Documentation preview 📚: https://cpython-previews--137334.org.readthedocs.build/