-
Notifications
You must be signed in to change notification settings - Fork 788
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
Simplify and fix cache volume locking #4352
Conversation
c857841
to
e7d6600
Compare
This adds no new tests:
|
Could we get this in first please #4349 and then we can rebase the current PR ? |
Sure. The overlap is actually pretty small. |
@mtrmac Could you rebase please :) |
They exist in memory anyway, so this is more efficient: we avoid the need to manually touch the filesystem again, the associated costs - and the error paths go away. [NO NEW TESTS NEEDED] Signed-off-by: Miloslav Trmač <[email protected]>
By construction it's now quite clear that the locks should always be locked. Don't even bother with AssertLockedForWriting(), that's partially (checking for lock ownership, not for read-write ownership) implied by Unlock() already. [NO NEW TESTS NEEDED] Signed-off-by: Miloslav Trmač <[email protected]>
Maintain a list of _all_ the locks, not just the last one. Signed-off-by: Miloslav Trmač <[email protected]>
It can return at most one lock, so don't return an array. Should not change behavior right now, but it will simplify cleanup. [NO NEW TESTS NEEDED] Signed-off-by: Miloslav Trmač <[email protected]>
Other then spelling mistake LGTM |
... and use a more traditional error handling model, where responsibility for the cleanup passes to the caller _only_ if the called function succeeds. To reinforce that, hard-code nil returns on error paths instead of returning the locks. Signed-off-by: Miloslav Trmač <[email protected]>
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.
/lgtm
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.
LGTM
/approve
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: flouthoc, mtrmac The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
What this PR does / why we need it:
sharing=locked
(an undocumented feature AFAICS): Pass around lock objects instead of files, completely eliminating various error pathsLockfile.Locked
, which is going away in API break: Remove Lockfile.Locked storage#1399 ).How to verify it
Existing tests? I didn’t even try running the code.
Which issue(s) this PR fixes:
None
Special notes for your reviewer:
Cc: @flouthoc who added the feature in #3820.
Does this PR introduce a user-facing change?