tough: Add locking around datastore write operations #497
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue #, if available: #117 (kinda)
Description of changes:
We don't want separate threads using tough to end up writing to its datastore and reading at the same time. #117 suggested making those operations take
&mut self
, but that bubbles up to requiring most methods onRepository
to also take&mut self
.This adds a
RwLock
toDatastore
, allowing "any number of readers to acquire the lock as long as a writer is not holding the lock".The difference between this and
&mut self
is that this is ensured at runtime, which may cause a deadlock (I'm not aware of a way this is possible, because the guard drops out of scope before a reader is even returned), as opposed to ensuring against a data race at compile time, which may just cause borrowck to yell politely at you.I've tested that this does not, in fact, cause a deadlock in updog.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.