Skip to content
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

refactor(state): avoid need for state lock in LatestWarningTime #493

Merged
merged 2 commits into from
Aug 29, 2024

Conversation

benhoyt
Copy link
Contributor

@benhoyt benhoyt commented Aug 27, 2024

This means that not every request/response needs to acquire the state lock, as shown by the removal of the custom response type in the /v1/health endpoint.

Note that there's a test, TestHealthStateLockNotHeldSuccess, that specifically tests that the state lock is not held during /v1/health requests. If we accidentally introduce locking again, that will fail.

Fixes #366.

This means that not every request/response needs to acquire the state
lock, as shown by the removal of the custom response type in the
/v1/health endpoint.

Note that there's a test, TestHealthStateLockNotHeldSuccess, that
specifically tests that the state lock is not held during /v1/health
requests. If we accidentally introduce locking again, that will fail.
@benhoyt benhoyt requested a review from hpidcock August 27, 2024 22:45
Copy link
Member

@hpidcock hpidcock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank-you for this follow up PR.

@@ -270,6 +270,13 @@ func (s *State) AddNotice(userID *uint32, noticeType NoticeType, key string, opt
notice.lastData = options.Data
notice.repeatAfter = options.RepeatAfter

// Update the latest warning time cache if needed. There's no need to
// actually update atomically here, because the state lock is held.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I was about to comment on that. Looks like you've already considered that. If we ever update this without the state mutex, then we'll need to reconsider this.

@benhoyt benhoyt merged commit 5cf80be into canonical:master Aug 29, 2024
17 checks passed
@benhoyt benhoyt deleted the atomic-warnings branch August 29, 2024 00:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Avoid acquiring state lock in Command.ServeHTTP
3 participants