Closed xacrimon closed 4 years ago
i think i'd feel more comfortable with this, if dashmap underwent a safety dance.
Well I'm on that team and have extensively concurrency tested it on high core count systems. There are relatively few that know enough to audit this well. And I don't know any with free time. But I will say I have tested it extensively by this point.
this is open source, no one is in a hurry, i hope.
anyway, what i'm trying to get at is that there's around 16 unsafe
APIs¹, but only 3 // # Safety
comments, and i think that ratio should change.
n.b.: i don't think that a library magically becomes safe to use, just because there's // # Safety
comments, but i do like to understand why the unsafe
is there, and what guarantees in the code there are for it to be contained.
does that make sense? am i making sense?
¹: my count might be off, i'm not very good at counting
That does make a lot of sense. I can try to annotate the rest with safety blocks though a lot of them will be very similar. I should do this anyway.
I've now documented every single unsafe block in the codebase, published a patch and updated the version in this PR.
This is an excellent change. Thanks and would be great to see more input from you regarding performance related code and discussions in the future.
This PR removes a few mutex locks where there may be contention and replaces them with more concurrency friendly alternatives.