Fix possibly huge memory leak caused by long lived CancellableManagerProvider #213
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A long lived CancellableManagerProvider could easily end up with very many “cancelled” Cancellable in it’s internal CancellableManager because this is only cleared when the Provider itself is cancelled. This can cause huge memory leaks in some cases, for example in the DebounceProcessor Since there is only ever one “not cancelled” CancellableManager provided by the CancellableManagerProvider, there is actually no need to keep the previously provided, now cancelled, CancellableManager. We now simply use the internalCancellableManagerRef. Also took the oportunity to make cancelPreviousAndCreate hopefully atomic be exposing and using getAndSet on AtomicReference
npresseault
approved these changes
Jan 8, 2024
smatte
requested changes
Jan 8, 2024
Boubalou
approved these changes
Jan 8, 2024
marclefrancois
commented
Jan 8, 2024
| cancellableManager.add(it) | ||
| return CancellableManager().also { cancellableManager -> | ||
| internalCancellableManagerRef.getAndSet(cancellableManager).cancel() | ||
| serialQueue.dispatch { |
There was a problem hiding this comment.
The usage of the serialQueue is to ensure sequential cancellation of currently returned ref
There was a problem hiding this comment.
This essentially mimicks the CancellableManager internal implementation to be on the safe side
marclefrancois
commented
Jan 8, 2024
| } | ||
| } | ||
|
|
||
| override fun cancel() { | ||
| cancellableManager.cancel() | ||
| serialQueue.dispatch { |
There was a problem hiding this comment.
The usage of the serialQueue is to ensure sequential cancellation of currently returned ref
smatte
approved these changes
Jan 8, 2024
marclefrancois
deleted the
fix/memory_leak_in_cancellable_manager_provider
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
A long lived CancellableManagerProvider could easily end up with very many “cancelled” Cancellable in it’s internal CancellableManager because this is only cleared when the Provider itself is cancelled.
This can cause huge memory leaks in some cases, for example in the DebounceProcessor
Since there is only ever one “not cancelled” CancellableManager provided by the CancellableManagerProvider, there is actually no need to keep the previously provided, now cancelled, CancellableManager.
We now simply use the internalCancellableManagerRef.
Also took the oportunity to make cancelPreviousAndCreate hopefully atomic be exposing and using getAndSet on AtomicReference
Motivation and Context
In certain realtime application, usage of
debounce()on long lived, shared publishers could cause immense memory leaksHow Has This Been Tested?
Types of changes