aio-libs / multidict / 36391160696

87%

push

github

Release the old pairs after re-initializing, not before (#1619)

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

## What do these changes do?

`md_init()` and `md_clone_from_ht()` called `md_clear()` and then stored
the new table a second time. `md_clear()` runs the old values'
finalizers while the multidict looks empty, so a `__del__` that added to
the multidict during `d.__init__(...)` on a live multidict had its pair
overwritten by the second store: the pair was lost, and the table it
went into leaked along with its references.

Both functions now go through one helper that publishes the new table,
`used` and the version in one step, records `CLEARED` or `CLONED`, and
only then drops the old table through `_md_release_keys()`. A finalizer
therefore sees the new contents (empty for the `md_init()` paths, since
the extend comes after; the copied pairs for the clone paths) and what
it adds stays. That is exactly what the pure-Python implementation
already did, so it needs no change. `md_clear()`'s own
publish-empty-first ordering is untouched, and a concurrent reader still
only ever sees a complete old or complete new table.

## Are there changes in behavior for the user?

Yes: a pair a finalizer adds while `__init__()` releases the old pairs
is kept instead of being lost and leaked. A watcher sees it reported
after `CLEARED` / `CLONED` instead of before, which is now documented in
`docs/capi.rst`.

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

No, it removes a publish and replaces two copies of the same sequence
with one helper.

## Related issue number

Follows #1618, which added `_md_release_keys()`.

## Checklist

- [x] I think the code is well written
- [x] Unit tests for the changes exist
- [x] Documentation reflects the changes
- [ ] If you provide code modification, please add yourself to
`CONTRIBUTORS.txt` (N/A)
- [x] Add a new news fragment into the `CHANGES/` folder
- [x] `make doc-spelling` passes and any new technical wor... (continued)

780 of 1560 branches covered (50.0%)

Branch coverage included in aggregate %.

62 of 81 new or added lines in 2 files covered. (76.54%)

8533 of 9122 relevant lines covered (93.54%)

1.87 hits per line