aio-libs / multidict / 35903992859

87%

push

github

Compute a key's identity outside the critical section (#1538)

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

## What do these changes do?

The single-key methods took `md`'s critical section in `_multidict.c`
and
`capsule.h`, and only then turned the key into its identity and hashed
it.
That work reads the key plus `md->is_ci` and `md->state`, both fixed for
the
object's lifetime, so it never needed the lock; on a free-threaded build
it
can also run Python (a `str` subclass's `lower()`, a finalizer), which
hits a
safepoint and suspends the section anyway.

`md_add()`, `md_del()`, `md_set_default()`, `md_pop_one()`,
`md_replace()`,
`md_get_all()` and `md_pop_all()` now compute the pair first and take
the
section themselves around a `_locked` helper, the shape `md_get_one()`
and
`md_contains()` already use. `md_replace()` stops taking a `reflist_t`
from
its caller; that parameter only existed because the caller owned the
section.
`md_walk()` splits into `md_walk_with_hash()` plus a wrapper so
`getall()` and
`MultiDict_ForEach()` hoist the hash too; the set operators in `views.h`
build
an identity per item inside a walk of their own and keep calling
`md_walk()`.

The pure-Python backend is deliberately untouched. It holds a
`threading.RLock` over whole method bodies for a different reason,
non-atomic
bytecode on every build, and this is internal lock granularity with no
observable behaviour change, so there is nothing for dual-backend
discipline
to mirror.

## Are there changes in behavior for the user?

No.

## Is it a substantial burden for the maintainers to support this?

No. It removes a `Py_BEGIN_CRITICAL_SECTION` from ten call sites and
leaves
the write path shaped like the read path.

## Related issue number

N/A

## Checklist

- [x] I think the code is well written
- [x] Unit tests for the changes exist
- [ ] Documentation reflects the changes — N/A, no user-visible API
change
- [ ] If you provide code modification, please add yourself to
`CONTRIBU... (continued)

765 of 1530 branches covered (50.0%)

Branch coverage included in aggregate %.

7221 of 7607 relevant lines covered (94.93%)

1.9 hits per line