You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of AbortSignal.any([...]) will lead to memory leaks if any of the provided signals are long-lived and retained in memory. A typical real-world example is a global shared signal that is only aborted when the process receives an interruption signal (i.e. SIGTERM or SIGINT).
AbortSignal.any seems to eagerly add a listener to each provided signal, regardless of whether the combined signal itself has any listener at all. As a consequence, the leak can also be observed with just this:
Perhaps we either accept that this is by design with AbortSignal.any, where it must not be used with any long-lived signal, or we should address this in the whatwg/dom proposed algorithm such that all downstream implementations correct this.
Version: Deno 1.45.5
The current implementation of
AbortSignal.any([...])
will lead to memory leaks if any of the provided signals are long-lived and retained in memory. A typical real-world example is a global shared signal that is only aborted when the process receives an interruption signal (i.e.SIGTERM
orSIGINT
).Here's a simple reproducer:
Running this will show a clear memory leak pattern of RSS growing rapidly:
2 things could be observed:
AbortSignal.any
seems to eagerly add a listener to each provided signal, regardless of whether the combined signal itself has any listener at all. As a consequence, the leak can also be observed with just this:AbortSignal.any
does not remove the listener from all provided signals uponremoveEventListener
being called on the combined signal.I believe one way to address this is to:
addEventListener
is called on the combined signalAs an example, here's a suggested implementation:
The text was updated successfully, but these errors were encountered: