diff options
| author | sentientwaffle <sentientwaffle@gmail.com> | 2021-12-14 13:25:23 -0800 |
|---|---|---|
| committer | Andrew Kelley <andrew@ziglang.org> | 2021-12-16 19:11:53 -0800 |
| commit | ef0566df7858df3a770a2b3112ca991358974be3 (patch) | |
| tree | bf4966f7cd3a7e6a988db12664f07756060053bb /lib/std/Thread/Mutex.zig | |
| parent | d54ba76e40232f9e8e3f784e927f3138bdd97520 (diff) | |
| download | zig-ef0566df7858df3a770a2b3112ca991358974be3.tar.gz zig-ef0566df7858df3a770a2b3112ca991358974be3.zip | |
std: count hash_map tombstones as available
When entries are inserted and removed into a hash map at an equivalent rate (maintaining a mostly-consistent total count of entries), it should never need to be resized. But `HashMapUnmanaged.available` does not presently count tombstoned slots as "available", so this put/remove pattern eventually panics (assertion failure) when `available` reaches `0`.
The solution implemented here is to count tombstoned slots as "available". Another approach (which hashbrown (https://github.com/rust-lang/hashbrown/blob/b3eaf32e608d1ec4c10963a4f495503d7f8a7ef5/src/raw/mod.rs#L1455-L1542) takes) would be to rehash all entries in place when there are too many tombstones. This is more complex but avoids an `O(n)` bad case when the hash map is full of many tombstones.
Diffstat (limited to 'lib/std/Thread/Mutex.zig')
0 files changed, 0 insertions, 0 deletions
