GeezerVison is showing github.com — Tracking issue for free-threading docs · Issue #145912 · python/cpython
Tracking issue for free-threading docs #145912DescriptionDocumentation
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)
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)
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
-
io types (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.Lock and other synchronization primitives
- Practical patterns: queues,
concurrent.futures, thread-local storage
- 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
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.dat entries match actual function signatures
- Consider generating per-module thread safety summary tables - especially in modules where it makes sense like
collections
Linked PRs
Activityespressolee commented on Aug 8, 2026 I'd like to pick up two of the unchecked items here: the PySequence_* abstract-layer
annotations (scoped to the PySequence_Fast* family first) and the reference-counting
annotations (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_Fast aliasing plus a stale _GET_SIZE (python-pillow/Pillow#9852), and a
non-atomic Py_XSETREF on a shared object's field (GrahamDumpleton/wrapt#347, where the
maintainer 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 main today: Doc/data/threadsafety.dat has no entries for
PySequence*, Py_SETREF, Py_XSETREF or Py_CLEAR; Doc/c-api/sequence.rst has no
thread-safety text at all; and the Py_SETREF entry in Doc/c-api/refcounting.rst covers only
the re-entrancy hazard (the existing free-threading notes there are on Py_REFCNT and
Py_SET_REFCNT). I have draft .. note:: text and .dat entries for both families.
Two questions before I open anything, because they look like framework decisions rather than
drafting ones:
- For these two families, do you want
.dat entries, .. note:: blocks, or both?
- How should the abstract layer's "safety depends on the concrete type" problem be represented
in the five-level scheme? PySequence_GetItem and friends dispatch to the concrete type, so
a 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 layer
alone.
One thing worth flagging for whoever writes this either way:
Py_BEGIN_CRITICAL_SECTION_SEQUENCE_FAST is internal-only
(Include/internal/pycore_critical_section.h), so it cannot be recommended to extension
authors — the advice has to be a snapshot or a plain critical section on the returned object. kojikojikojikoji commented on Oct 21, 2026 I'd like to work on the collections.deque item, in the same style as the list and dict sections. Is anyone already working on it?
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|