-
Notifications
You must be signed in to change notification settings - Fork 10
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
feat: make cleaner safe for concurrent use #552
Conversation
8692777
to
33d6b7a
Compare
33d6b7a
to
81921a0
Compare
c.lock.RLock() | ||
defer c.lock.RUnlock() |
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.
I'm not sure in practice if this will end up mattering, but it seems a bit odd to make the actual cleanup a "ready only" lock, considering all the mutations it's making.
Actually, it occurs to me now that what we should probably do is lock the object and block all future changes once we've run cleanup. E.g. any Add
to the cleaner fails after Cleanup
is called.
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.
I've create an issue to track this: #563.
This should be OK for now (at least for our internal usage). We might take another approach at this when indeed we use cleaners more than once.
No description provided.