Fix memory leak in AbortSignal.any in environments with weak data structures #81
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.
The current implementation of
AbortSignal.any
has two factors that lead to a memory leakAbortSignal.any
is called, it adds a new event handler to the given signalsabort
event handler keeps a hard reference to the new "any" signal created, which does not allow the garbage collector to remove it from memory as long as the given signals are in memory.The issue is apparent when you have a long-lived signal that is used as an argument to
AbortSignal.any
.Solution
EventTarget
constructor if available. EventTarget uses aSet
structure under the hood, so handlers are only added onceDebugging
I used the following script to visualize the memory issue
These are the logs from each implementation
Current implementation
Fixed implementation
Related issues