-
-
Notifications
You must be signed in to change notification settings - Fork 406
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use lock for map iteration #1366
Conversation
I'm not quite sure why that test is failing. It's not something I've touched with my code and I can't reproduce on my Windows machine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me :)
Thank you! One change I had considered but not implemented was instead of using a lock count, and the guard having a |
Yes. I think this is much better idea |
I don't think is a problem, at least for now, If we wanted to implement
It seems sound to me as well, And I think having the struct guard is the easier and cleaner way to do it. |
Actually, I've just had a go at implementing this and come up against the obstacle that there would be no way to trigger the |
Hmmm. Yeah that is a problem. In that case lets leave it with this implementation. |
On more inspection |
Fixed tests:
|
Hey @joshwd36 you interested on also solving this for |
I should be able to, I'll see if I have any time |
Sorry for the delay, I've done this now. |
This Pull Request fixes #1092.
It changes the following:
OrderedMap
to aMapKey
, which contains either a key or an empty value.Concerns/Questions
indexmap::Equivalent
traitOrderedMap
now has the key as aValue
rather than a generic parameter. I think this should be fine as I don't think there are other uses ofOrderedMap
that might require a different key. It may even be possible to implement theEquivalent
trait in such a way that it allows the generic parameter to be maintained, but I couldn't find one with a fair amount of experimentation.MapLock
struct is sound, but there might be a better way to do it. I originally just had methods to lock and unlock that would be called before and after iteration, but if an error occured during iteration the unlock function would never be called.lock
?