respond to review, add image

Author: ngoldbaum

apps/labs/posts/free-threaded-one-year-recap.md

@@ -5,26 +5,22 @@ published: May 12, 2025
 description: 'A recap of the first year of work on enabling support for the free-threaded build of CPython in community packages.'
 category: [Community, PyData ecosystem]
 featuredImage:
-  src: /posts/hello-world-post/featured.png
-  alt: 'Excellent alt-text describing the featured image'
+  src: /posts/free-threaded-one-year-recap/native-extension-diagram.png
+  alt: 'A diagram illustrating how Python code can directly C, C++, or Rust code'
 hero:
-  imageSrc: /posts/hello-world-post/hero.jpeg
-  imageAlt: 'Excellent alt-text describing the hero image'
+  imageSrc: /posts/free-threaded-one-year-recap/native-extension-diagram.png
+  imageAlt: 'A diagram illustrating how Python code can directly C, C++, or Rust code'
 ---
 
 Last week, the CPython developers rolled out CPython 3.14.0b1. This week, PyCon 2025 kicks off in Pittsburgh, PA. Both events mark a significant milestone for the effort to ship and stabilize free-threaded Python.
 
 This is the story of the first year of that effort and how our team at Quansight played a key role in enabling experimental use of the free-threaded build with real production workflows that depend on a complex set of dependencies.
 
-## Introduction: What is free-threaded Python and why are we working on it?
+## Introduction: Why are we working on community support for free-threaded Python?
 
-Currently, CPython is shipping two different "builds" of the interpreter. One build works the same as CPython has always worked: there is a single "global" lock in the interpreter that prevents more than one thread from calling into the CPython C API simultaneously. This is usually referred to as the Global Interpreter Lock, or just GIL for short. The new "free-threaded" build does not have this limitation: many threads can simultaneously call into the CPython C API and the GIL is disabled by default. Instead of a single global lock to ensure synchronization between threads, state is synchronized using per-object locks or careful orchestration via low-level lock-free implementations of mutable data structures.
+Support for free-threaded Python unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resources in Python requires workarounds and careful tuning. The Python `threading` module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for `multiprocessing`, but spawning processes is expensive and communicating across processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
 
-The benefit of making this change is that it unlocks the full compute power of modern hardware with multicore CPUs and GPUs now commonplace. In the GIL-enabled build, making full use of parallel algorithms that exploit all available compute resources in Python requires workarounds and careful tuning. The Python `threading` module is often not used because the GIL prevents useful parallel scaling. Instead, many reach for `multiprocessing`, but spawning processes is expensive and communicating across processes often requires making expensive copies of data that would not be necessary in a multithreaded program where data is implicitly shared between threads.
-
-Disabling the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the `threading` module, even with the GIL, most of the time the GIL prevented these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
-
-This is why it is not possible for packages to "automatically" support the free-threaded build. Any package shipping native code (many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package.
+We need to work to add add support for free-threaded Python because it is not possible for packages that ship compiled code in their release distributions to "automatically" support the free-threaded build. Any package shipping native code (many Python packages do that) will need to be audited to ensure the package builds and either fix or document the safety guarantees provided by the package. Disabling the GIL required deep structural changes to the CPython interpreter. Fully supporting the free-threaded build in existing packages similarly requires fixing structural issues that until now were not big problems. Things like use of global state in the implementation of a C extension for convenience or for performance are no longer safe, since the GIL does not protect simultaneous access from Python to the global state, allowing undefined behavior via data races. While it is possible to trigger thread safety issues like this using the `threading` module, even with the GIL, most of the time the GIL prevented these issues from surfacing. The free-threaded build makes fixing these issues much more pressing.
 
 ## Major accomplishments
 
@@ -33,14 +29,16 @@ With assistance from the team at Meta driving free-threaded support there and in
   * Packaging and project workflow tools like meson, meson-python, the setup-python GitHub workflow, packaging, pip, and setuptools.
   * Bindings generators like Cython, pybind11, f2py, and PyO3.
   * Foundational packages in the PyData ecosystem like NumPy, SciPy, PyArrow, matplotlib, Pandas, scikit-learn, and scikit-image.
-  * Top dependencies by PyPI downloads like Pillow, yarl, multidict, and frozenlist.
+  * Top dependencies by PyPI downloads like Pillow, PyYAML, yarl, multidict, and frozenlist.
 
-We are also currently looking at popular packages that don't yet ship support, including CFFI, PyYAML, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenizers.
+We are also currently looking at popular packages that don't yet ship support, including CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, and grpcio as well as popular libraries for machine learning workflows like safetensors and tokenizers.
 
-CPython core developers on our team also contributed several major improvements that will be shipped in CPython 3.14:
+CPython core developers on our team also contributed several major improvements that will ship in CPython 3.14:
 
-  * The Python warnings module is now thread-safe by default on the free-threaded build. It can be made thread-safe on the GIL-enabled build with a configuration option or runtime command-line flag.
-  * Significant thread safety issues in asyncio have been fixed. Our benchmarks indicate substantially improved parallel scaling of code using asyncio with a thread pool runner as a function of thread count.
+  * The Python `warnings` module is now thread-safe by default on the free-threaded build. It can be made thread-safe on the GIL-enabled build with a configuration option or runtime command-line flag.
+  * Significant thread safety issues in `asyncio` have been fixed. Our benchmarks indicate substantially improved parallel scaling of code using asyncio with a thread pool runner as a function of thread count.
+  * Thread safety overhaul in the `ctypes` module.
+  * Substantial performance improvements for the free-threaded garbage collector.
   * Helped implement and ship the deferred reference counting scheme used by the free-threaded interpreter in 3.14.
   * Implemented several specializations for the adaptive specializing interpreter and supported shipping optimizations that bring the single-threaded performance of free-threaded CPython 3.14 within spitting distance of the GIL-enabled build.
   * A huge number of smaller bugfixes and thread safety improvements.