- From: James M Snell <notifications@github.com>
- Date: Wed, 24 Nov 2021 16:00:38 -0800
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/pull/1032/c978503712@github.com>
I think the issue is more that the timer can continue well after the set of operations completed successfully. Take a pathological case where I create an `AbortSignal` with a timeout of 20 minutes and I attach a handler to it with a closure. ```js const signal = AbortSignal.timeout(1_200_000); signal.addEventListener('abort', () => { throw signal.reason; }); ``` The complete set of operations that I pass the `signal` to complete successfully, but the internal timer for the `signal` keeps right on going, holding the `AbortSignal` and the closure (along with whatever memory it's closing over) for the whole 20 minutes. Then, it unconditionally throws a synchronous error. Ideally there would be a way of canceling the timeout. Obviously that doesn't help with the closure holding on to things but it ensures that the underlying timer it at least no holding the reference for way longer than it needs to. ```js const signal = AbortSignal.timeout(1_200_000); await fetch('http://example.org', { signal }); signal.clearTimeout(); ``` This case is similar to why we allowed adding an `AbortSignal` to `addEventListener()` itself. We can even follow a similar pattern here if necessary: ```js const cancelAbort = AbortController(); const signal = AbortSignal.timeout(1_200_000, { signal: cancelAbort.signal }); signal.addEventListener('abort', () => { throw signal.reason; }, { signal: cancelAbort.signal }); await fetch('http://example.org', { signal }); cancelAbort.abort(); ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/pull/1032#issuecomment-978503712
Received on Thursday, 25 November 2021 00:00:51 UTC