Repository navigation
Tracking issue for free-threading docs #145912
Description
Documentation
Summary
This is a tracking issue for the ongoing effort to improve thread safety documentation in CPython, covering both Python-level guarantees for built-in types and C API-level annotations for extension authors.
Completed work
Thread safety page and built-in type guarantees (gh-142518)
- Define free-threading related terms in the glossary
- gh-142518: Document thread-safety guarantees of list operations #142519
- gh-142518: Document thread-safety guarantees of dict operations #144184
- gh-142518: Move thread safety sections into a new page #144716
- gh-142518: Improve mimalloc allocator docs #145224
C API thread safety annotations (gh-145254)
- Define five annotation levels:
incompatible,compatible,distinct,shared,atomic - gh-145254: Add thread safety annotation #145255
- Add thread safety levels reference section to
threadsafety.rst - Open python-docs-theme PR for rendering support
In progress (at the time of writing)
- gh-142518: Document thread-safety guarantees of set objects #145225
- gh-142518: Document thread-safety guarantees of bytearray objects #145226
- gh-142518: Add thread safety notes for the buffer protocol #145911
- gh-142518: Annotate PyDict_* C APIs for thread safety #145875
- gh-142518: Annotate PyList_* C APIs for thread safety #146109
Remaining work
stdlib type documentation
After built-in types, document thread-safety guarantees for stdlib types. Suggested priority:
-
collections.deque- widely used as a thread-safe queue substitute; people already assume it's safe; heavily used in asyncio internals -
iotypes (BufferedReader,BufferedWriter,TextIOWrapper) - file I/O is inherently concurrent in real programs; existing thread-safety notes are scattered and incomplete -
collections.defaultdict- the__missing__call introduces non-obvious concurrency questions (factory call is not atomic with insertion) -
collections.OrderedDict- has its own internal locking that differs from plain dict -
collections.Counter- commonly used for aggregation across threads -
array.array- mutable typed array, relevant for numeric/scientific code going parallel
Rationale: deque first because it's the most likely to be shared across threads today. io types next because concurrent file access is common and the current docs are inadequate. The collections types after that, ordered by usage frequency and concurrency risk. array.array last - niche usage, but mutable so still worth documenting.
Free-threading programming guide (new HOWTO)
A new Doc/howto/free-threading-guide.rst, alongside the existing two free-threading HOWTOs. The existing free-threading-python.rst stays focused on "what is free-threading / what changed." The new guide focuses on how to write correct concurrent code.
Topics to cover:
- Single operations vs. compound operations - why "thread-safe" doesn't mean "atomic"
- Common pitfalls: check-then-act, read-modify-write, iterating shared containers
- When and how to use
threading.Lockand other synchronization primitives - Practical patterns: queues,
concurrent.futures, thread-local storage - How to migrate existing threaded code that relied on the GIL
- Testing and debugging strategies (ThreadSanitizer, running under free-threaded builds)
- Summary reference table of built-in type thread safety (quick lookup, links to detailed per-type docs)
Cross-reference from free-threading-python.rst and from the per-type thread safety page.
asyncio free-threaded guide
Other documentation gaps
- Review and improve
queuemodule docs w.r.t. free-threaded builds - Address Multiprocessing docs don't describe thread-safety #84992
- Address Document os.environ[x] = y and os.putenv() as thread unsafe #83556
C API annotations
- Annotate
PyObject_*APIs (creation, attribute access, comparison, etc.) - Annotate abstract layer APIs
-
PySequence_* -
PyMapping_* -
PyNumber_* -
PyIter_*
-
- Annotate reference counting APIs (
Py_INCREF,Py_DECREF,Py_NewRef, etc.) - Annotate GIL/critical-section APIs
- Annotate concrete type APIs
-
PyList_* -
PyDict_* -
PySet_* -
PyTuple_* -
PyUnicode_*
-
- Annotate buffer protocol APIs (
PyObject_GetBuffer,PyBuffer_Release, etc.) - Systematically work through remaining high-usage C API functions
Infrastructure improvements
- Coordinate with Audit all built-in modules for thread safety #116738 (audit all built-in modules for thread safety) - ensure doc annotations stay in sync with implementation fixes
- Add CI/linting to validate
threadsafety.datentries match actual function signatures - Consider generating per-module thread safety summary tables - especially in modules where it makes sense like
collections
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsTodo
Activity
espressolee commentedon Aug 8, 2026
I'd like to pick up two of the unchecked items here: the
PySequence_*abstract-layerannotations (scoped to the
PySequence_Fast*family first) and the reference-countingannotations (starting with
Py_SETREF/Py_XSETREF).Motivation: while testing C extensions on the free-threaded build I reproduced
segfault/double-free crashes in released packages that map exactly onto these two undocumented
spots —
PySequence_Fastaliasing plus a stale_GET_SIZE(python-pillow/Pillow#9852), and anon-atomic
Py_XSETREFon a shared object's field (GrahamDumpleton/wrapt#347, where themaintainer acknowledged the mechanism and chose documented higher-level locking over a C fix).
gh-150044 is the related proposal for internal atomic setrefs; the discussion there notes the
public macros cannot simply become atomic because the loads would have to be atomic too — which
is exactly why callers need something written down.
Current state, checked against
maintoday:Doc/data/threadsafety.dathas no entries forPySequence*,Py_SETREF,Py_XSETREForPy_CLEAR;Doc/c-api/sequence.rsthas nothread-safety text at all; and the
Py_SETREFentry inDoc/c-api/refcounting.rstcovers onlythe re-entrancy hazard (the existing free-threading notes there are on
Py_REFCNTandPy_SET_REFCNT). I have draft.. note::text and.datentries for both families.Two questions before I open anything, because they look like framework decisions rather than
drafting ones:
.datentries,.. note::blocks, or both?in the five-level scheme?
PySequence_GetItemand friends dispatch to the concrete type, soa single level seems wrong; I would rather not invent a convention here. That is also why I
have scoped my draft to the
PySequence_Fast*family and left the rest of the abstract layeralone.
One thing worth flagging for whoever writes this either way:
Py_BEGIN_CRITICAL_SECTION_SEQUENCE_FASTis internal-only(
Include/internal/pycore_critical_section.h), so it cannot be recommended to extensionauthors — the advice has to be a snapshot or a plain critical section on the returned object.