Repository navigation
Tracking issue for free-threading docs #145912
Description
Activity
- added3.14bugs and security fixesbugs and security fixes3.15bugs and security fixesbugs and security fixes
on Mar 13, 2026 I'd like to pick up two of the unchecked items here: the
PySequence_*abstract-layer
annotations (scoped to thePySequence_Fast*family first) and the reference-counting
annotations (starting withPy_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 a
non-atomicPy_XSETREFon 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
maintoday:Doc/data/threadsafety.dathas no entries for
PySequence*,Py_SETREF,Py_XSETREForPy_CLEAR;Doc/c-api/sequence.rsthas no
thread-safety text at all; and thePy_SETREFentry inDoc/c-api/refcounting.rstcovers only
the re-entrancy hazard (the existing free-threading notes there are onPy_REFCNTand
Py_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:- For these two families, do you want
.datentries,.. 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_GetItemand 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 thePySequence_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_FASTis 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.- For these two families, do you want
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsTodo
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)
C API thread safety annotations (gh-145254)
incompatible,compatible,distinct,shared,atomicthreadsafety.rstIn 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 internalsiotypes (BufferedReader,BufferedWriter,TextIOWrapper) - file I/O is inherently concurrent in real programs; existing thread-safety notes are scattered and incompletecollections.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 dictcollections.Counter- commonly used for aggregation across threadsarray.array- mutable typed array, relevant for numeric/scientific code going parallelRationale:
dequefirst because it's the most likely to be shared across threads today.iotypes next because concurrent file access is common and the current docs are inadequate. Thecollectionstypes after that, ordered by usage frequency and concurrency risk.array.arraylast - 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 existingfree-threading-python.rststays focused on "what is free-threading / what changed." The new guide focuses on how to write correct concurrent code.Topics to cover:
threading.Lockand other synchronization primitivesconcurrent.futures, thread-local storageCross-reference from
free-threading-python.rstand from the per-type thread safety page.asynciofree-threaded guideOther documentation gaps
queuemodule docs w.r.t. free-threaded buildsC API annotations
PyObject_*APIs (creation, attribute access, comparison, etc.)PySequence_*PyMapping_*PyNumber_*PyIter_*Py_INCREF,Py_DECREF,Py_NewRef, etc.)PyList_*PyDict_*PySet_*PyTuple_*PyUnicode_*PyObject_GetBuffer,PyBuffer_Release, etc.)Infrastructure improvements
threadsafety.datentries match actual function signaturescollections