GeezerVison

readline.get_completer() reads state->completer and returns a new reference without taking the module critical section, while set_completer() swaps the same field under the critical section with Py_XSETREF. On the free-threaded build a concurrent getter can be incrementing the refcount of a hook the setter is simultaneously dropping. get_pre_input_hook() has the same problem with state->pre_input_hook — those are the only two hook fields with both a Py_XSETREF-based setter and a Python-level getter, so this covers the whole Python-visible getter surface.

The fix adds @critical_section to both getters, the same way gh-126895 did for the rest of the module.

Verified with a free-threaded TSAN build (--disable-gil --with-thread-sanitizer): the reproducer from the issue reports the race on main (the readline_get_completer read vs the set_hook write) and runs clean with this change. The new tests in test_readline.py trigger the same TSAN reports without the fix and pass with it.

Deliberately not included here: get_begidx()/get_endidx() and the C callback paths (on_completion() etc.) read module state without the critical section too, but their writer/reader sides live in readline callbacks (flex_complete(), on_hook()), where taking the module critical section is a design question (it would serialize completion callbacks against all other readline calls) — that's a follow-up, not a one-line annotation.

I used AI assistance while working on this change; I've reviewed it and can explain it.

• Issue: Data race in readline.get_completer() reads state->completer without the critical section #153291