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

Fix a locking issue in the Rollback manager #6426

Merged
merged 10 commits into from
Mar 18, 2019
Merged

Conversation

briankassouf
Copy link
Contributor

No description provided.

@briankassouf briankassouf added this to the 1.1 milestone Mar 18, 2019
michelvocks
michelvocks previously approved these changes Mar 18, 2019
Copy link
Contributor

@michelvocks michelvocks left a comment

Choose a reason for hiding this comment

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

Overall LGTM. One minor minor adjustment.

vault/rollback.go Outdated Show resolved Hide resolved
ncabatoff
ncabatoff previously approved these changes Mar 18, 2019
vault/rollback.go Outdated Show resolved Hide resolved
@briankassouf briankassouf dismissed stale reviews from ncabatoff and michelvocks via 9b7fdf3 March 18, 2019 15:40
vault/rollback.go Outdated Show resolved Hide resolved
@briankassouf briankassouf merged commit d8038ea into master Mar 18, 2019
@briankassouf briankassouf deleted the fix-rollback-locks branch March 18, 2019 18:12
return rsInflight
}

cancelCtx, cancelFunc := context.WithCancel(context.Background())
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this not derive the context using the ctx param and not context.Background()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think it's necessary, doesn't need to be tied to any other external states

// If we stopped due to shutdown, return. Otherwise another thread
// is holding the lock for us, continue on.
select {
case <-m.shutdownCh:
Copy link
Contributor

Choose a reason for hiding this comment

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

Will it be possible to read from this channel both in here and in the goroutine above?

Copy link
Contributor

Choose a reason for hiding this comment

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

In the above goroutine, in case of a shutdown, stopCh will be closed by reading m.shutdownCh. We are trying to read from the same again here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You can read from a closed channel multiple times

Copy link
Collaborator

Choose a reason for hiding this comment

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

Remember that a receive from a closed channel returns immediately. So that's okay, we're not trying to consume anything, just use it as a signal.

@vishalnayak
Copy link
Contributor

@briankassouf This is already merged but I had 2 minor comments. Otherwise it looked good.

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.

5 participants