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

For an example use case from Cloudflare Workers...

First, some background: 

The fetch [`Request` object](https://fetch.spec.whatwg.org/#request-class) can receive an `AbortSignal` as part of it's initialization. It also has it's own `AbortSignal` that the spec calls "this's signal". On initialization of the `Request` object, "this's signal" is set to follow the `signal` passed on init *only if the init signal is provided*. If the init signal is not provided, then there is nothing that will ever trigger `this's signal`.

When the `Request` object is cloned, the clones `signal` is set to follow `this's signal`, which may not ever actually be triggered by anything.

In the Workers implementation of fetch, we are able to use the fact that we know that certain `AbortSignal`s will never actually be aborted as an indicator that we are able to ignore it safely. In such cases, we are simply able to skip adding the additional logic that handles the cancelation. We keep track of whether an `AbortSignal` can actually be triggered by anything using an internal flag that is essentially equivalent to the proposed `closed` flag (it's currently named something else but it doesn't matter).

The tl;dr is -- It's helpful to know if I actually need to pay attention to the `AbortSignal`. If there's nothing that can trigger it, then I can ignore it. Given the note in the spec: "... an API observing the AbortSignal object can choose to ignore them.", then "closed" is effectively a strong hint that it can do so.

Whether that's enough of a justification is up for debate :-)

@MattiasBuelens:
> 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".

It's not entirely that simple. Many uses simply *can't* remove their abort algorithms if they no longer have a handle to the algorithm itself. For instance, passing in an anonymous handler `signal.addEventListener('abort', () => { ... })`, or adding those in a different scope. 

@domenic:
> Is it OK that you can add abort listeners after closing? They won't be triggered by abort() (since abort() is a no-op after closing in the proposal), but they still exist.

I think so. Having the `closed` attribute set is enough of a signal. If someone ignores it and adds handlers anyway, then that's on them.



-- 
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-989320817