(Possible) free-threading TODO list?

[clin1234]

Free-Threading Analysis Report

Generated with https://github.com/devdanzin/ft-review-toolkit, in conjunction with Claude Code

Extension: cffi / _cffi_backend (9 C files, ~12,900 lines)

Main entry: src/c/_cffi_backend.c (monolithic, includes all other .c files)
Thread headers: misc_thread_common.h, misc_thread_posix.h, misc_win32.h
Agents run: shared-state-auditor · ft-history-analyzer · lock-discipline-checker ·
atomic-candidate-finder · unsafe-api-detector · stop-the-world-advisor

---

Migration Status

Status: CLOSE — cffi completed a substantial free-threading port (PR #178, 2025)
and has declared Py_MOD_GIL_NOT_USED for both module entry points.
Six actionable findings remain before the declaration is fully correct.

Indicator	Location	Meaning
PyUnstable_Module_SetGIL(m, Py_MOD_GIL_NOT_USED)	_cffi_backend.c:7944, cffi1_module.c:135	Module declares free-threading support
suppressions_free_threading.txt	repo root	TSan suppressions in place (all CPython-internal races, none cffi-owned)
PyMutex unique_cache_lock	_cffi_backend.c:398	Per-mutex protecting unique_cache
cffi_atomic_load/store	misc_thread_posix.h, misc_win32.h	C11 __ATOMIC_SEQ_CST atomics for both POSIX and MSVC
cffi_check_flag/cffi_set_flag	misc_thread_common.h:397–401	Atomic byte-flag macros for per-type state
CFFI_LOCK/CFFI_UNLOCK	misc_thread_common.h:410–411	Critical section via Py_BEGIN_CRITICAL_SECTION(&_dummy)
#ifdef Py_GIL_DISABLED pre-init loop	realize_c_type.c:77–85	Eagerly populates all_primitives[] before parallel access
pytest-run-parallel / @thread_unsafe markers	testing/conftest.py	Parallel test harness wired up

---

Executive Summary

• Readiness: Close
• RACE findings: 6 — confirmed data races requiring immediate fixes
• UNSAFE findings: 2 — operations unsafe without GIL
• PROTECT findings: 1 — lock re-entrancy design issue
• MIGRATE findings: 3 — structural changes for long-term correctness

---

Findings by Priority

RACE Findings (fix immediately) — 6

#	Finding	File:Line	Severity	Agents
1	externpy->reserved1/reserved2: pre-GIL plain read + concurrent write-write race	call_python.c:249, 170–175, 132–135	CRITICAL	shared-state, atomics, unsafe-apis, locks
2	interpdict check-then-act in _get_interpstate_dict — first callers race on PyDict_GetItem+SetItem	call_python.c:42–51	HIGH	unsafe-apis
3	static PyObject *attr_name lazy-init without atomics	call_python.c:14, 36–40	HIGH	atomics, unsafe-apis, locks
4	zombie_next unlocked fast-path read in thread_canary_free_zombies	misc_thread_common.h:150	HIGH	unsafe-apis
5	LIB_GET_OR_CACHE_ADDR check-then-build-insert on lib->l_dict without a lock	lib_obj.c:443–452	MEDIUM	locks, shared-state
6	_testfunc6 static local int y[] shared across threads	_cffi_backend.c:7410	LOW	manual (test-only)

---

Finding 1 — externpy->reserved1/reserved2 pre-GIL + write-write race

File: src/c/call_python.c

cffi_call_python() is the entry point for every extern "Python" callback. It reads
externpy->reserved1 before acquiring the GIL (line 249):

// line 249 — no lock, no atomic, GIL not yet held:
if (externpy->reserved1 == NULL) {
    err = 1;
} else {
    PyGILState_STATE state = gil_ensure();          // GIL acquired HERE
    if (externpy->reserved1 != _current_interp_key()) {  // line 256
        err = _update_cache_to_call_python(externpy);
    }
    if (!err) {
        general_invoke_callback(0, args, args, externpy->reserved2);  // line 263
    }
}

_update_cache_to_call_python (line 170–175) writes both fields:

externpy->reserved1 = new1;         // plain pointer write — no atomic, no lock
externpy->reserved2 = infotuple;    // plain pointer write — no atomic, no lock

_ffi_def_extern_decorator (line 132–135) also writes reserved1:

externpy->reserved1 = Py_None;      // plain pointer write

Under free-threading, PyGILState_Ensure() provides no mutual exclusion — it
only ensures the calling thread has a thread state. Two threads can both miss the
reserved1 != _current_interp_key() check, both enter _update_cache_to_call_python,
and both write reserved1/reserved2 concurrently — producing:

1. Write-write race on reserved1/reserved2 — undefined behavior under C11.
2. Double Py_XDECREF of old1/old2 — both threads read the pre-update values,
   both decref them; whichever thread stores last causes a premature free on the
   object freed by the other thread.
3. Torn-pointer read at line 249 — the pre-GIL reserved1 == NULL test is a
   plain C load racing with a write on another thread.

reserved2 is read at line 263 after gil_ensure(), but its write at line 173 has
no ordering fence relative to the check at line 256 — a reader can see reserved1
updated but reserved2 still stale, then call general_invoke_callback with a
stale (or freed) infotuple.

Note: struct _cffi_externpy_s is ABI-stable (shipped in parse_c_type.h and
baked into generated modules). Its field types cannot change. Use the existing
cffi_atomic_load(void**) / cffi_atomic_store(void**) macros.

Fix:

// In cffi_call_python (line 249) — atomic read before GIL:
if (cffi_atomic_load((void **)&externpy->reserved1) == NULL) {

// In _update_cache_to_call_python (lines 170–175) — store reserved2 FIRST:
old1 = (PyObject *)cffi_atomic_load((void **)&externpy->reserved1);
old2 = (PyObject *)cffi_atomic_load((void **)&externpy->reserved2);
cffi_atomic_store((void **)&externpy->reserved2, infotuple);  // reserve2 first
cffi_atomic_store((void **)&externpy->reserved1, new1);       // then reserved1
Py_XDECREF(old1);
Py_XDECREF(old2);

// In _ffi_def_extern_decorator (line 133):
cffi_atomic_store((void **)&externpy->reserved1, Py_None);

Store ordering (reserved2 before reserved1) is intentional: readers check
reserved1 first; once they see a non-NULL matching the interp key, they must see
the updated reserved2.

For the check-then-update sequence at lines 256–263, wrap with CFFI_LOCK() to
prevent the write-write race entirely. The atomic stores in _update_cache_to_call_python
are the minimum fix; CFFI_LOCK() is the complete fix.

---

Finding 2 — interpdict check-then-act in _get_interpstate_dict

File: src/c/call_python.c:42–51

_get_interpstate_dict() is on the hot callback path
(cffi_call_python → _update_cache_to_call_python → _get_interpstate_dict).
It performs a check-then-act on the interpreter-state dict:

d = PyDict_GetItem(interpdict, attr_name);   // line 42 — check
if (d == NULL) {
    d = PyDict_New();                        // line 44 — allocate
    ...
    err = PyDict_SetItem(interpdict, attr_name, d);  // line 47 — insert
    ...
}
return d;

interpdict is PyInterpreterState_GetDict(interp) — shared across all threads of
the same interpreter. Under free-threading, two threads can both observe d == NULL,
each allocate a new dict, and the second PyDict_SetItem silently replaces the first.

Impact: Any @ffi.def_extern() registrations stored by the first thread's dict
are irretrievably lost. Later calls to that extern function return err = 3
("@ffi.def_extern() was not called in the current subinterpreter") and produce
incorrect zero-return behavior logged to stderr.

Note: ffi_obj.c:1032 already uses PyObject_CallMethod(cache, "setdefault", ...)
specifically to avoid this race — the same pattern is needed here.

Fix: Use PyDict_SetDefault() (Python 3.13+ internal API, thread-safe) or
setdefault idiom:

// Option A: PyDict_SetDefault (Python 3.13+, internally atomic):
d = PyDict_New();
if (d == NULL) goto error;
{
    PyObject *existing = PyObject_CallMethod(interpdict, "setdefault",
                                             "OO", attr_name, d);
    Py_DECREF(d);
    if (existing == NULL) goto error;
    d = existing;
}
return d;

---

Finding 3 — static PyObject *attr_name lazy-init without atomics

File: src/c/call_python.c:14, 36–40

static PyObject *attr_name = NULL;   // line 14

static PyObject *_get_interpstate_dict(void) {
    ...
    if (attr_name == NULL) {                              // line 36 — plain read
        attr_name = PyUnicode_InternFromString("...");   // line 37 — plain write
        ...
    }
}

This is called from cffi_call_python (multi-threaded C callback context).
Two threads can both observe attr_name == NULL and both write it. The plain
pointer write/read pair is a data race under the C11 memory model even though
PyUnicode_InternFromString returns the same interned object to both threads.

Fix (preferred — eager init at module load):

// In PyInit__cffi_backend() or init_ffi_lib(), before Py_MOD_GIL_NOT_USED:
static PyObject *attr_name;
attr_name = PyUnicode_InternFromString("__cffi_backend_extern_py");
if (attr_name == NULL) INITERROR;

Fix (alternative — atomic lazy-init):

PyObject *local = (PyObject *)cffi_atomic_load((void **)&attr_name);
if (local == NULL) {
    local = PyUnicode_InternFromString("__cffi_backend_extern_py");
    if (local == NULL) goto error;
    cffi_atomic_store((void **)&attr_name, local);
}
// use local, not attr_name

---

Finding 4 — zombie_next unlocked fast-path read

File: src/c/misc_thread_common.h:150

static void
thread_canary_free_zombies(void)
{
    if (cffi_zombie_head.zombie_next == &cffi_zombie_head)  // plain read, no lock
        return;   /* fast path */
    ...
    TLS_ZOM_LOCK();
    ...
    TLS_ZOM_UNLOCK();
}

cffi_zombie_head.zombie_next is written inside thread_canary_make_zombie() and
_thread_canary_detach_with_lock(), both of which require TLS_ZOM_LOCK(). The
fast-path read at line 150 acquires neither TLS_ZOM_LOCK nor uses cffi_atomic_load.

Under free-threading, a thread shutting down (without the GIL) writes zombie_next
while another thread reading it at line 150 produces a C11 data race on a pointer
that is sizeof(void*) wide.

Fix:

if (cffi_atomic_load((void **)&cffi_zombie_head.zombie_next) ==
        (void *)&cffi_zombie_head)
    return;

cffi_atomic_load is already defined in misc_thread_posix.h:59 and
misc_win32.h:227; this is a one-line fix.

---

Finding 5 — LIB_GET_OR_CACHE_ADDR check-then-build-insert

File: src/c/lib_obj.c:443–452

#define LIB_GET_OR_CACHE_ADDR(x, lib, name, error)      \
    do {                                                \
        x = PyDict_GetItem(lib->l_dict, name);          \
        if (x == NULL) {                                \
            x = lib_build_and_cache_attr(lib, name, 0); \
            if (x == NULL) { error; }                   \
        }                                               \
    } while (0)

lib_build_and_cache_attr ends with PyDict_SetItem(lib->l_dict, name, x).
The check-build-insert triple is not atomic. Two threads calling lib.some_func
simultaneously can both miss the cache, both build a PyCFunctionObject, and both
insert — the second insert replaces the first, leaking the first thread's object.

The individual PyDict_* calls are internally thread-safe in CPython 3.13+'s
free-threaded build, but the logical atomicity of the three-step sequence is not
preserved. In cases where lib_build_and_cache_attr involves realize_c_type (for
OP_GLOBAL_VAR / OP_EXTERN_PYTHON), CFFI_LOCK inside realize_c_type_or_func
provides secondary protection against double-realization; the primary waste is the
leaked object.

Fix: Wrap with Py_BEGIN_CRITICAL_SECTION(lib):

#define LIB_GET_OR_CACHE_ADDR(x, lib, name, error)              \
    do {                                                         \
        Py_BEGIN_CRITICAL_SECTION((PyObject *)(lib));            \
        x = PyDict_GetItemWithError(lib->l_dict, name);          \
        if (x == NULL && !PyErr_Occurred())                      \
            x = lib_build_and_cache_attr(lib, name, 0);         \
        if (x != NULL) Py_INCREF(x);                            \
        Py_END_CRITICAL_SECTION();                               \
        if (x == NULL) { error; }                               \
    } while (0)

Check that lib_build_and_cache_attr does not call back through the same lib
object (it calls realize_c_type, which uses CFFI_LOCK on _dummy, not on lib,
so re-entrancy through lib's per-object lock does not occur).

---

Finding 6 — _testfunc6 static local int y[]

File: src/c/_cffi_backend.c:7410

static int *_testfunc6(int *x)
{
    static int y[50];   // shared across threads
    memcpy(y, x, 50 * sizeof(int));
    return y;
}

This function is compiled into the module for test purposes only. Under concurrent
--parallel-threads test execution, two threads calling _testfunc6 simultaneously
race on y. No production code path calls this function.

Fix: Remove static (or allocate y on the heap and require callers to free it).
Since this is a test helper, the minimal fix is removing static:

int y[50];   // stack-allocated, no longer shared

---

UNSAFE Findings (fix before declaring free-threading support) — 2

#	Finding	File:Line	Severity	Agents
7	dlerror() Windows shim writes into static char buf[32] — shared across threads	misc_win32.h:205–213	HIGH	manual
8	PyDict_GetItem borrowed ref on interpstate_dict used after Py_DECREF gap	call_python.c:162–169	MEDIUM	unsafe-apis

---

Finding 7 — dlerror() Windows static buffer

File: src/c/misc_win32.h:205–213

static char *dlerror(void)
{
    static char buf[32];    // shared mutable buffer
    snprintf(buf, sizeof(buf), "Error %lu", GetLastError());
    return buf;
}

On Windows, cffi provides its own dlerror() shim that writes into a static char
buffer and returns a pointer to it. Under free-threading, two threads calling
dlerror() simultaneously race on buf: one thread's error message is overwritten
by the other before the first thread reads it.

Fix: Use a thread-local buffer:

static char *dlerror(void)
{
    static __thread char buf[32];   // thread-local on GCC/Clang
    snprintf(buf, sizeof(buf), "Error %lu", GetLastError());
    return buf;
}

On MSVC: use __declspec(thread) instead of __thread. Alternatively, use
cffi_tls_s (the existing TLS struct in misc_thread_common.h) to store this buffer.

---

Finding 8 — Borrowed ref from PyDict_GetItem on concurrently-written dict

File: src/c/call_python.c:162–169

infotuple = PyDict_GetItem(interpstate_dict, interpstate_key);  // borrowed ref
Py_DECREF(interpstate_key);   // ← gap here
if (infotuple == NULL)
    return 3;
...
Py_INCREF(infotuple);         // ← incref only happens here

interpstate_dict is the per-interpreter @ffi.def_extern() registry. Under
free-threading, _ffi_def_extern_decorator can write to it concurrently (it holds
only the GIL, which is no longer exclusive). Between the PyDict_GetItem (line 162)
and Py_INCREF(infotuple) (line 168), Py_DECREF(interpstate_key) runs — if this
key's finalizer triggers Python code that removes an entry from interpstate_dict,
the borrowed infotuple becomes dangling.

In practice interpstate_key is a freshly-allocated PyLong_FromVoidPtr, so its
destructor cannot reach interpstate_dict. The immediate risk is low, but the
pattern is a documented anti-pattern under free-threading.

Fix: Replace with the existing PyDict_GetItemRef shim
(already defined at _cffi_backend.c:150):

if (PyDict_GetItemRef(interpstate_dict, interpstate_key, &infotuple) <= 0) {
    Py_DECREF(interpstate_key);
    return 3;
}
Py_DECREF(interpstate_key);
// infotuple now has a strong reference — use and Py_DECREF when done

---

PROTECT Findings (add synchronization) — 1

#	Finding	File:Line	Severity	Agents
9	Nested CFFI_LOCK: _realize_c_struct_or_union re-acquires CFFI_LOCK while it is held, silently suspending the outer critical section	realize_c_type.c:451, 753, 897	MEDIUM	locks

---

Finding 9 — Nested CFFI_LOCK suspension via Py_BEGIN_CRITICAL_SECTION re-entrancy

File: src/c/realize_c_type.c

CFFI_LOCK() expands to Py_BEGIN_CRITICAL_SECTION(&_dummy). CPython's
critical_section.h (lines 55–58) documents:

"Critical sections implicitly behave like reentrant locks because
attempting to acquire the same lock will suspend any outer
(earlier) critical sections."

This means that if a call path already inside CFFI_LOCK() re-enters
CFFI_LOCK() (on the same _dummy object), the outer critical section is
silently released for the duration of the inner one.

The re-entrant path exists in two forms:

Path A — realize_c_type_or_func (line 752–757) acquires CFFI_LOCK, then inside
realize_c_type_or_func_lock_held calls _realize_c_struct_or_union (line 451),
which calls do_realize_lazy_struct (line 576), which acquires CFFI_LOCK again
(line 897).

Path B — b_complete_struct_or_union (line 5537) acquires CFFI_LOCK, calls
b_complete_struct_or_union_lock_held, which at line 5210 calls
force_lazy_struct(ftype) → do_realize_lazy_struct(ftype) → CFFI_LOCK again.

During the suspension window, another thread that acquires CFFI_LOCK can enter
do_realize_lazy_struct_lock_held for the same ct while the original thread
is still constructing it. The ct_under_construction flag (set atomically at line 875)
provides a secondary guard: a concurrent thread will see ct_under_construction == 1
and fail the guard at b_complete_struct_or_union_lock_held:5172. This prevents a
double-completion but creates a confusing "error: internal error" return for the
second thread.

This does not cause a deadlock — CPython's critical sections deliberately avoid
deadlock by suspending rather than blocking. However, the design is fragile and
relies on secondary flag checks to compensate for the gap.

Fix: Replace do_realize_lazy_struct (which acquires CFFI_LOCK from scratch)
with a _lock_held variant in both re-entrant call sites:

// realize_c_type.c: inside _realize_c_struct_or_union() — already under CFFI_LOCK:
if (do_realize_lazy_struct_lock_held(ct) < 0)   /* was: do_realize_lazy_struct */
    return NULL;

// _cffi_backend.c: inside b_complete_struct_or_union_lock_held(), line 5210 — already under CFFI_LOCK:
if (do_realize_lazy_struct_lock_held(ftype) < 0)   /* was: force_lazy_struct */
    goto finally;

This eliminates the suspension window entirely. The _lock_held suffix convention is
already established in the codebase.

---

MIGRATE Findings (structural changes) — 3

#	Finding	File:Line	Severity	Agents
10	m_size = -1 precludes per-interpreter module state; incompatible with sub-interpreter safety	cffi1_module.c:99, _cffi_backend.c:7923	MEDIUM	manual
11	Static PyTypeObject objects instead of heap types; prevents per-interpreter type isolation	_cffi_backend.c:290–296	MEDIUM	manual
12	Mixed lock domains: ct->ct_stuff uses per-object CS; other ct fields use CFFI_LOCK	_cffi_backend.c:2580–2586	LOW	manual

---

Finding 10 — m_size = -1 global module state

Files: src/c/cffi1_module.c:99, src/c/_cffi_backend.c:7923

Both module definitions set m_size = -1 (no per-interpreter module state). This
is incompatible with multi-phase module initialization (Py_mod_exec) and means
that all global statics (unique_cache, all_primitives, g_ct_voidp, etc.) are
shared across sub-interpreters in the same process.

For the current embedding / extension use cases this is acceptable. For long-term
correctness under Isolated Sub-Interpreters (PEP 684), m_size should be set to
sizeof(cffi_module_state_t) with a matching m_clear / m_traverse to hold
per-interpreter references.

Fix (longer-term): Define a cffi_module_state_t struct, migrate per-interpreter
globals into it, implement Py_mod_exec slot for initialization, and set
m_size = sizeof(cffi_module_state_t).

---

Finding 11 — Static PyTypeObject objects

File: src/c/_cffi_backend.c:290–296

cffi defines its types as static PyTypeObject objects:

static PyTypeObject CData_Type = { ... };
static PyTypeObject CType_Type = { ... };
...

Static type objects are shared across sub-interpreters. When/if cffi migrates to
per-interpreter state (Finding 10), these should become heap-allocated types
(PyType_FromSpec) to ensure each interpreter has its own type object with its own
tp_dict.

Fix (longer-term): Use PyType_FromSpec with a PyType_Spec for each type.
This is a significant refactor best done after Finding 10 is resolved.

---

Finding 12 — Mixed lock domains for ct->ct_stuff

File: src/c/_cffi_backend.c:2580–2586

ct->ct_stuff (the lazy array-type pointer in cdata_slice) is initialized under
Py_BEGIN_CRITICAL_SECTION(ct) — the per-object lock on the individual
CTypeDescrObject. All other ct mutations use CFFI_LOCK() (the module-level
critical section on _dummy). These are two distinct lock domains guarding different
fields of the same ct struct.

Currently there is no overlap (no field is guarded by both locks), so this is safe.
However, the asymmetry is a maintenance hazard: a future change that reads ct_stuff
inside CFFI_LOCK() while a writer has Py_BEGIN_CRITICAL_SECTION(ct) would create
an undetected ordering issue.

Fix (longer-term): Document this invariant in a comment, or consolidate all
lazy-init paths on ct to use the same lock domain.

---

SAFE Patterns (confirmed safe — no action needed)

Pattern	Location	Why safe
unique_cache dict	_cffi_backend.c:398–400, 4648–4676	PyMutex unique_cache_lock guards all reads/writes; init under import lock
all_primitives[] array	realize_c_type.c:19, 77–85	#ifdef Py_GIL_DISABLED pre-init loop populates all slots at module init; read-only thereafter
cffi_zombie_lock, cffi_zombie_head list	misc_thread_common.h:47–49, 85	TLS_ZOM_LOCK() guards all list mutations; cffi_zombie_lock init is under import lock
cffi_tls_index / cffi_tls_key TLS handle	misc_win32.h:13, misc_thread_posix.h:22	Written once during module init under import lock; stable pointer thereafter
static char init_done in PyInit__cffi_backend	_cffi_backend.c:7911	Accessed only inside module init, serialized by CPython's per-interpreter import lock
static char init_done in init_ffi_lib	cffi1_module.c:27	Called from PyInit__cffi_backend; same import-lock protection
builder->ctx.types[] opcode slots	realize_c_type.c:443, 453, 594, 738	Written via cffi_atomic_store(); read via _CFFI_LOAD_OP() → cffi_atomic_load()
ct_lazy_field_list, ct_under_construction, ct_unrealized_struct_or_union flags	misc_thread_common.h:397–401	Accessed only via cffi_check_flag() / cffi_set_flag() → __ATOMIC_SEQ_CST atomics
ct_flags_mut field	_cffi_backend.c:229–235	Comment documents: "read/set without atomic because CFFI_LOCK is held"
cdata_slice lazy ct->ct_stuff	_cffi_backend.c:2580–2586	Py_BEGIN_CRITICAL_SECTION(ct) serializes the once-init
ffi_init_once cache	ffi_obj.c:999–1004	Py_BEGIN_CRITICAL_SECTION(self) correctly paired
_embedding.h startup	_embedding.h:70–103, 386–464	CAS spinlock + reentrant mutex + write/read barriers; correct and complete
PyWeakref_GetObject shim	_cffi_backend.c:165–180	#if PY_VERSION_HEX < 0x030d00a1 — unreachable under free-threading (3.13+)
PyIOBase_TypeObj	file_emulator.h:4	Initialized once in init_file_emulator() under module init; read-only after
malloc_closure.h statics	malloc_closure.h:31, 74, 85, 86	MALLOC_CLOSURE_LOCK() → PyMutex guards all reads/writes
CFFI_LOCK → unique_cache_lock ordering	_cffi_backend.c:4648, realize_c_type.c:753	Lock order is globally acyclic: CFFI_LOCK always outer, unique_cache_lock always inner
TLS_ZOM_LOCK pairing	misc_thread_common.h:109, 157, 278	All three acquisition sites are correctly paired with no early-exit between lock and unlock
PyErr_Occurred() / PyErr_Clear()	all .c files	Per-PyThreadState — no cross-thread sharing
Py_DECREF on locally owned references	all .c files	Free-threading uses per-thread reference counting; only the reserved1/reserved2 path (Finding 1) is a concern

---

Recommendations

Immediate (RACE items — Findings 1–4)

1. Fix Finding 1 — Atomic access to externpy->reserved1/reserved2

In src/c/call_python.c, change all four access sites to use cffi_atomic_load
and cffi_atomic_store. Ensure reserved2 is stored before reserved1. Wrap the
check-update-use sequence in cffi_call_python (lines 255–265) with
CFFI_LOCK()/CFFI_UNLOCK() to eliminate the write-write race entirely. This is
the highest-severity fix in the codebase.

2. Fix Finding 2 — Use setdefault for interpdict initialization

In _get_interpstate_dict() (line 42–51), replace the GetItem+SetItem pair with
a setdefault-based approach (PyObject_CallMethod(interpdict, "setdefault", ...))
or PyDict_SetDefault() to make the check-and-insert atomic.

3. Fix Finding 3 — Move attr_name init to module startup

Initialize static PyObject *attr_name during PyInit__cffi_backend() (or
init_ffi_lib()), before Py_MOD_GIL_NOT_USED is declared. Remove the runtime
lazy-init check entirely. This is the same pattern already applied to all_primitives
under #ifdef Py_GIL_DISABLED.

4. Fix Finding 4 — Atomic fast-path read of zombie_next

In thread_canary_free_zombies() (line 150), replace the plain pointer comparison
with cffi_atomic_load((void **)&cffi_zombie_head.zombie_next). One line change.

Short-term (RACE + UNSAFE items — Findings 5–8)

5. Fix Finding 5 — Serialize LIB_GET_OR_CACHE_ADDR

Wrap the LIB_GET_OR_CACHE_ADDR macro body in Py_BEGIN_CRITICAL_SECTION(lib) in
lib_obj.c. Ensure lib_build_and_cache_attr does not re-enter through the lib
object's per-object lock (it uses CFFI_LOCK on _dummy, so there is no conflict).

6. Fix Finding 6 — Remove static from _testfunc6

Change static int y[50] to int y[50] in _cffi_backend.c:7410. Stack-allocate
the array. This is a one-word change.

7. Fix Finding 7 — Thread-local dlerror() buffer on Windows

In misc_win32.h, add __declspec(thread) (MSVC) or __thread (GCC/Clang) to
buf in the dlerror() shim, or store the buffer in cffi_tls_s.

8. Fix Finding 8 — Replace borrowed ref with PyDict_GetItemRef

In call_python.c:162–169, use PyDict_GetItemRef(interpstate_dict, ...) (the shim
is already defined at _cffi_backend.c:150) to obtain a strong reference before the
Py_DECREF(interpstate_key) gap.

Medium-term (PROTECT item — Finding 9)

9. Fix Finding 9 — Eliminate nested CFFI_LOCK suspension

Add do_realize_lazy_struct_lock_held() and call it directly from
_realize_c_struct_or_union() (line 451) and from within
b_complete_struct_or_union_lock_held() (line 5210, via an inline call replacing
force_lazy_struct). This eliminates the window where the outer CFFI_LOCK is
silently suspended.

Longer-term (MIGRATE items — Findings 10–12)

10–12. Migrate to per-interpreter module state (m_size > 0), heap type objects
(PyType_FromSpec), and a unified lock domain for ct fields. These are significant
refactors best staged after the immediate fixes ship.

---

Suggested Next Steps

# Install pytest-run-parallel:
python3t -m pip install pytest-run-parallel

# Run the test suite under free-threading with parallel threads:
python3t -m pytest testing/cffi1/ --parallel-threads=4 -x -q

# Generate a TSan stress test:
# /ft-review-toolkit:explore . stress-test

# Run under a TSan-enabled Python build, then triage the report:
# /ft-review-toolkit:explore . tsan tsan_report.txt

# When all RACE/UNSAFE items are fixed, re-run this analysis:
# /ft-review-toolkit:explore

---

Cross-Agent Deduplication Notes

The following issues were flagged by multiple agents and counted once:

Issue	Agents	Resolution
externpy->reserved1/reserved2	shared-state (PROTECT HIGH), atomics (PROTECT HIGH), unsafe-apis (RACE HIGH), locks (RACE HIGH)	Counted once as Finding 1 — RACE CRITICAL
attr_name lazy-init	atomics (PROTECT MEDIUM), unsafe-apis (RACE HIGH), locks (RACE MEDIUM)	Counted once as Finding 3 — RACE HIGH
LIB_GET_OR_CACHE_ADDR TOCTOU	shared-state, locks	Counted once as Finding 5 — RACE MEDIUM

---

Generated by ft-review-toolkit:explore on 2026-06-13
Python 3.14t (Py_GIL_DISABLED=1 confirmed) · cffi 2.0.1.dev0
Agents: shared-state-auditor · ft-history-analyzer · lock-discipline-checker · atomic-candidate-finder · unsafe-api-detector · stop-the-world-advisor

[mattip]

Please don't post AI content here with no human input. What do you personally propose to do about these findings? Did you verify them? How do they relate to open PRs around free threading?