aio-libs / multidict / 35619716719

87%

push

github

Stop a GIL-releasing __del__ from segfaulting the standard C extension build (#1491)

<!-- Thank you for your contribution! -->

## What do these changes do?

Extends the deferred-decref technique from #1487 (free-threaded builds
only) to the standard, GIL-enabled C extension build. On that build
`Py_BEGIN_CRITICAL_SECTION` compiles to a no-op, so a decref whose
`__del__` (or a weakref callback) itself releases the GIL was the only
thing standing between a mutation and a second thread running
concurrently
on the very same `MultiDict`; nothing caught that. `update()`,
`merge()`,
`__setitem__()`, `__delitem__()`, `pop()`, `popone()`, and `popall()`
now
defer every such decref until the mutation has fully finished, the same
way the free-threaded build already does. `md_clear()` needed no change:
it already swaps `md->keys` to the empty table before releasing any
reference, so a suspended decref there can only ever be observed against
a fully detached old table.

Also bumped the deferred-decref accumulator's inline buffer from 8 to
1024 entries so the allocator is essentially never reached in practice.

A related, pre-existing gap was found but is intentionally **not** fixed
here (see the follow-up note below): `md_del()`/`popall()`'s own
multi-entry loops cache the entries array and iterator once at loop
start
and never refresh them the way `_md_replace()`/`_md_update()` do, so a
decref-triggered suspension mid-loop can leave them pointing at a table
a
concurrent resize already freed. This reproduces identically on
unmodified upstream `master`, on both builds, so it predates this PR.

C extension only; the pure-Python implementation has no locking of its
own to regress.

## Are there changes in behavior for the user?

Yes: a value type whose `__del__` (or a weakref callback) releases the
GIL while another thread concurrently mutates the same `MultiDict` no
longer risks a segfault or table corruption on the standard build.
Single-threaded behavior is unch... (continued)

762 of 1524 branches covered (50.0%)

Branch coverage included in aggregate %.

45 of 45 new or added lines in 1 file covered. (100.0%)

6514 of 6786 relevant lines covered (95.99%)

1.92 hits per line