Re: [whatwg/dom] AbortController.prototype.timeout and AbortController.prototype.cancel (Issue #1039)

It's possible to *not* have `close()`, as long as all operations that add an abort algorithm *also remove their abort algorithm* once they've completed "normally".

Unfortunately, we're not even doing that in the specifications. See for example:
* [EventTarget](https://dom.spec.whatwg.org/commit-snapshots/982c7e2b710326167d718b85f83a5734fdb5619d/#add-an-event-listener)'s add an event listener, step 5
* [fetch()](https://fetch.spec.whatwg.org/commit-snapshots/6257e220d70f560a037e46f1b4206325400db8dc/#dom-global-fetch) step 10
* [Web Locks](https://w3c.github.io/web-locks/#request-a-lock)'s request a lock, step 2
* [Prioritized Task Scheduling](https://wicg.github.io/scheduling-apis/#schedule-a-task-to-invoke-a-callback)'s schedule a task to invoke a callback, step 6

The only spec I found that does this properly is [Streams](https://streams.spec.whatwg.org/commit-snapshots/21a81c60873903324a0b9c57b4b27f8928492720/#readable-stream-pipe-to), where `pipeTo()` properly removes its abort algorithm in "finalize".

Maybe we should first fix how abort signals are used inside other specifications, and that might eliminate the need for a dedicated `AbortController.close()`? 🙂

-- 
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/issues/1039#issuecomment-989301586