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

Adds Signal.WaitForStateMinWithCleanup to avoid leaking waiters #397

Merged
merged 3 commits into from
Dec 9, 2022

Conversation

chrisfjones
Copy link
Contributor

@chrisfjones chrisfjones commented Oct 13, 2022

If Signal.WaitForState* is called multiple times for a state like "stopping", the waiters will remain in the signal's queue forever and their channel will remain open. This has happened in my case while calling PartitionProcessor.VisitValues multiple times. This was causing Signal.waiters to grow indefinitely and cause a memory leak.
This change adds a cleanup function to allow a caller to remove itself from the Signal.waiters list if it no longer cares about waiting for the given state.

fixes #398

chrisfjones and others added 3 commits October 12, 2022 17:04
This converts the `Signal.waiters` list into a map and adds a `WaitForStateMinWithCleanup` that returns a function to allow the caller to remove the waiter from the list when it is done.
Adds Signal.WaitForStateMinWithCleanup
Copy link
Contributor

@frairon frairon left a comment

Choose a reason for hiding this comment

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

Thanks a lot for the fix!

@@ -107,6 +109,26 @@ func (s *Signal) WaitForStateMin(state State) <-chan struct{} {
return s.waitForWaiter(state, w)
}

// WaitForStateMinWithCleanup functions identically to WaitForStateMin, but returns a cleanup function in addition
// so that the caller can cleanup resources if it no longer wants to wait
func (s *Signal) WaitForStateMinWithCleanup(state State) (<-chan struct{}, func()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

The name sounds a bit clumsy to be honest, almost like java :D, but I don't have a better idea and introducing breaking changes just for this seems overkill. The signal implementation never was the finest piece of software in the first place, so maybe let's just do it the way you proposed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, I struggled a bit with the naming 😆
If there are more cases where this cleanup is needed down the road, the interface could be simplified and just always provide it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@frairon any idea what's up with the actions failures? It seems to be because it's running from my fork?

Copy link
Contributor

Choose a reason for hiding this comment

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

very sorry for the long delay. Let's just keep it that way and merge it.
Also, don't worry about the actions, they're quite flaky right now and we'll try to take care of it.

@frairon
Copy link
Contributor

frairon commented Dec 9, 2022

sorry again for the very long delay, I'll merge that now, many thanks for the fix!

@frairon frairon merged commit 3104848 into lovoo:master Dec 9, 2022
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.

Bug: PartitionProcessor.VisitValues does not clean up Signal.waiters, causing a memory leak
2 participants