GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Tracking issue for free-threading docs · Issue #145912 · python/cpython

Tracking issue for free-threading docs #145912

New issue
Copy link
New issue
Copy link
Open
Open
Tracking issue for free-threading docs#145912
Copy link
Labels
3.14bugs and security fixesbugs and security fixes3.15bugs and security fixesbugs and security fixesdocsDocumentation in the Doc dirDocumentation in the Doc dirtopic-free-threading

Description

@lysnikolaou
lysnikolaou
opened on Mar 13, 2026
Issue body actions

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

  • add asyncio guide for Free-Threaded Python #150456

Other documentation gaps

  • Review and improve queue module 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.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

  • gh-145912: Fix stale and incorrect free-threading statements in the docs #161162
  • gh-145912: Add a free-threading section on testing with ThreadSanitizer #161165
  • gh-145912: Fix some out of date or now missing FT documentation #161516

Activity

  1. lysnikolaou
    added
    docsDocumentation in the Doc dirDocumentation in the Doc dir
    on Mar 13, 2026
  2. github-project-automation
    added this to docs issueson Mar 13, 2026
  3. github-project-automation
    moved this to Todo in docs issueson Mar 13, 2026
  4. lysnikolaou
    added
    topic-free-threading
    3.14bugs and security fixesbugs and security fixes
    3.15bugs and security fixesbugs and security fixes
    on Mar 13, 2026
  5. espressolee commented on Aug 8, 2026

    @espressolee
    espressolee
    on Aug 8, 2026
    Contributor
    More actions

    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.

  6. kojikojikojikoji commented on Oct 21, 2026

    @kojikojikojikoji
    kojikojikojikoji
    on Oct 21, 2026
    More actions

    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?

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 fixesbugs and security fixes3.15bugs and security fixesbugs and security fixesdocsDocumentation in the Doc dirDocumentation in the Doc dirtopic-free-threading

    Projects

    • docs issues
      Status
      Todo
      Show more project fields

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    You are visitor 01402520 — GeezerVison does not store the pages you look up.
    Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.