Jake Archibald

> You can forget to remove the listener correctly when the resource is finished and leak memory. Just to clarify, the resource only stays in memory until `signal` is GC'd,...

@benjamingr is there a real example you could point to that would benefit from this? I find that I'm either using checkpoints, which is why I proposed https://github.com/whatwg/dom/issues/927, or I'm...

It isn't clear to me how a promise that only ever resolves on 'abort' solves the problem. Doesn't that just become a different leak point?

Here's my understanding of the problem: An async task uses a signal to know when/if the task should be aborted. The listener the async task adds to the signal is...

Based on the idea that a solution needs to have some knowledge of the length of the async task, here's a pattern: ```js function abortableSetTimeout(ms, { signal } = {})...

I gave it a spin on [squoosh.app](https://squoosh.app), which uses abort signals quite a bit https://github.com/GoogleChromeLabs/squoosh/pull/954/files - it helped in one place! The other helpers I needed were [`assetNotAborted`](https://github.com/whatwg/dom/issues/927), and a...

The second one. The implementation works, so you can test it yourself.

I don't have strong feelings about my version vs @Jamesernator's. It avoids the `setOnAbort` callback pattern mine has, which is good if we think my callback pattern is a bit...

Makes sense! Yeah, I guess the same as the promise design, it's nice that it still helps use-cases that depend on pulling the insides outsides (I've run into these cases...

@Jamesernator I'm not sure I follow. Are you saying your proposal should change or should stay as it is?