Skip to content

Tracking issue for free-threading docs #145912

Description

@lysnikolaou

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)

  • 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
  • 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

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

Activity

  1. espressolee commented on Aug 8, 2026

    @espressolee

    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:

    1. For these two families, do you want .dat entries, .. note:: blocks, or both?
    2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.14bugs and security fixes3.15bugs and security fixesdocsDocumentation in the Doc dirtopic-free-threading

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions