You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CPython's C API documentation has no systematic way to communicate the thread safety guarantees of individual APIs. As the free-threaded build matures, this information is increasingly important for extension authors.
This is analogous to how return value ownership is documented today, with automatically-inserted "Return value: New reference." / "Return value: Borrowed reference." annotations. We should do the same for thread safety.
Proposed levels
Three levels, ordered from least to most safe:
Thread-incompatible: Not safe even with external locking
Thread-compatible: Safe if the caller serializes all access with external locks
Safe: Safe to call from multiple threads on shared objects
Each annotation links to the corresponding glossary term. The thread-safe term already exists in the glossary, thread-compatible and thread-incompatible would be added.
I have PRs ready for both CPython and python-docs-theme. Feedback welcome, especially on the choice and naming of levels.
Documentation
CPython's C API documentation has no systematic way to communicate the thread safety guarantees of individual APIs. As the free-threaded build matures, this information is increasingly important for extension authors.
This is analogous to how return value ownership is documented today, with automatically-inserted "Return value: New reference." / "Return value: Borrowed reference." annotations. We should do the same for thread safety.
Proposed levels
Three levels, ordered from least to most safe:
Each annotation links to the corresponding glossary term. The
thread-safeterm already exists in the glossary,thread-compatibleandthread-incompatiblewould be added.I have PRs ready for both CPython and python-docs-theme. Feedback welcome, especially on the choice and naming of levels.
Linked PRs