Merging this PR will not alter performance

✅ 242 untouched benchmarks

_{Comparing Vizonex:md-repr-ft (3093e13) with master (e71a593)}

Thanks for tackling this @Vizonex. I think there's a lock-release bug in the current form, though: the critical section is opened at the top of md_repr, but Py_END_CRITICAL_SECTION() is only in the fail: block. md_repr has three returns that don't go through fail: — the success return return PyUnicodeWriter_Finish(writer);, the "MultiDict changed during iteration" return NULL;, and the early if (writer == NULL) return NULL; — so on the common (successful) path the section is entered and never ended, which leaves md locked and unbalances the thread's critical-section stack.

On a free-threaded build that should deadlock as soon as the same object is repr()'d a second time (the first repr() never released the lock):

# free-threaded build (Py_GIL_DISABLED), single thread is enough:
from multidict import MultiDict
md = MultiDict([("a", 1)])
repr(md)   # success path returns WITHOUT Py_END_CRITICAL_SECTION -> md stays locked
repr(md)   # re-enters Py_BEGIN_CRITICAL_SECTION(md) on the same thread -> hangs

If CI is green it's worth checking that tests/isolated/multidict_repr_ft.py actually re-reprs the same object after a successful one — the loop should hit this. A single exit, or a Py_END_CRITICAL_SECTION() before each return, fixes it. Two smaller notes: the "changed during iteration" path also still return NULLs without PyUnicodeWriter_Discard(writer), so it leaks the writer (a separate, pre-existing bug from the #1306 report); and this may be redundant with #1317, which already wraps every md_repr caller in a critical section — if #1317 lands, md_repr is covered at the call site and this PR might not be needed, so it's worth deciding which one owns it so they don't double up.

Thanks for tackling this @Vizonex. I think there's a lock-release bug in the current form, though: the critical section is opened at the top of md_repr, but Py_END_CRITICAL_SECTION() is only in the fail: block. md_repr has three returns that don't go through fail: — the success return return PyUnicodeWriter_Finish(writer);, the "MultiDict changed during iteration" return NULL;, and the early if (writer == NULL) return NULL; — so on the common (successful) path the section is entered and never ended, which leaves md locked and unbalances the thread's critical-section stack.

On a free-threaded build that should deadlock as soon as the same object is repr()'d a second time (the first repr() never released the lock):

# free-threaded build (Py_GIL_DISABLED), single thread is enough:
from multidict import MultiDict
md = MultiDict([("a", 1)])
repr(md)   # success path returns WITHOUT Py_END_CRITICAL_SECTION -> md stays locked
repr(md)   # re-enters Py_BEGIN_CRITICAL_SECTION(md) on the same thread -> hangs

If CI is green it's worth checking that tests/isolated/multidict_repr_ft.py actually re-reprs the same object after a successful one — the loop should hit this. A single exit, or a Py_END_CRITICAL_SECTION() before each return, fixes it. Two smaller notes: the "changed during iteration" path also still return NULLs without PyUnicodeWriter_Discard(writer), so it leaks the writer (a separate, pre-existing bug from the #1306 report); and this may be redundant with #1317, which already wraps every md_repr caller in a critical section — if #1317 lands, md_repr is covered at the call site and this PR might not be needed, so it's worth deciding which one owns it so they don't double up.

@devdanzin The other maintainers and I are still debating on Free-Threaded support, while we don't necessary see a need for it to be included I'm glad your still keeping us going. I might return to this bug fix if I feel more encouragement though. There was also an idea to move to Rust (Pyo3) to stop a lot of these noticeable memory leaks and other related bugs but the probability of that happing is very small as I see rust hindering the current performance benefits.