Free‑GIL build: compatibility of legacy C‑extensions

Direct answer

CPython does not publish a catalog of named legacy C extensions that fail in the 3.13 free‑threaded build. The documentation describes compatibility classes by code pattern, not by package. The likely explanation for failures is that many extensions implicitly rely on the GIL to serialize access to shared C state—global caches, borrowed references, refcounts, or non‑reentrant libraries—so removing the GIL exposes latent races.

Confirmed facts versus likely explanation

Confirmed: the free‑threaded interpreter uses a separate ABI; extensions must be rebuilt against free‑threaded headers. The module definition can declare Py_mod_gil = Py_MOD_GIL_NOT_USED, but that is an opt‑in assertion of thread safety, not a compatibility flag. The build also changes reference‑counting behavior, adding overhead that is separate from correctness risks.

Likely explanation: extensions with static mutable state, lazy initialization, direct refcount manipulation, or calls into non‑thread‑safe C libraries are the highest risk. Extensions with no shared state and single‑threaded entry points are lower risk, but still unverified until stress‑tested.

Pattern	Risk in free‑GIL
Global/static mutable state	High — races on shared C data
Lazy initialization caches	High — double init or torn writes
Borrowed PyObject* after GIL release	High — lifetime violations
Non‑reentrant C library calls	High — internal library state corruption
No shared state, single‑threaded entry	Lower — still needs rebuild and stress test

Mitigations without rewriting the extension

• Stay on the default GIL build for unported modules. This is the safest production choice today.
• Isolate the extension in a separate process if you must use the free‑threaded runtime. A process boundary restores serialization without changing the extension.
• Coarse mutex around Python‑visible entry points can be a stopgap only when the extension has no internal threads and no reentrant callbacks. A Python‑level lock does not protect C code that runs after releasing the GIL or that calls back into Python.

If you can rebuild, treat the free‑threaded ABI as a separate target and audit globals, caches, and borrowed PyObject* lifetimes before opting in to Py_MOD_GIL_NOT_USED. Note that Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS are not a free‑threading fix; object access and lifetime rules still apply.

Timeline

There is no confirmed stable release date for free‑threading and no announced deprecation schedule for the standard GIL build. Python 3.13 should be treated as experimental for production C‑extension compatibility decisions. Check the current PEP 703 status and release notes for your exact target version before committing.

Verification steps

1. Run the same multithreaded workload under the default GIL interpreter and the free‑threaded interpreter.
2. Rebuild the extension against free‑threaded headers and inspect its module definition for the GIL opt‑in.
3. If adding a coarse mutex around entry points removes failures, shared C state is the likely cause.

One diagnostic detail changes the recommendation: does the extension spawn internal threads or call back into Python? If yes, prefer process isolation or a real thread‑safety port over a wrapper lock.