Re: [whatwg/dom] Timeout AbortSignal (or AbortController) that gets input from the operation (Issue #1082)

Thinking about this more. I think what I'd like to see here are several additional APIs for both `AbortController` and `AbortSignal`.

* `AbortController.prototype.cancel()` (or `.close()`) -- Indicates that the `AbortSignal` will never be triggered, signaling to it that any abort event handlers can be released.
* `AbortSignal.prototype.cancel()` (or `.close()`) -- Like above.
* `AbortSignal.prototype.reset()` -- Reset the `AbortSignal` to the intial state. If there is a timer, for instance, the timer is reset. If the signal is already triggered, resets the state so that it can be triggered again, clearing the stored reason.

I would go with either all three or only the last two.

Examples:

```js
const signal = AbortSignal.timeout(10_000);
// ...
signal.reset(); // resets the timer to 10_000
//
signal.cancel(); // clears the timer, the signal will never trigger
```

```js
const ac = new AbortController();
const signals = AbortSignal.any([ac.signal, AbortSignal.timeout(10_000)]);
ac.cancel();
// signals will only follow the timeout signal now

signals.reset();
// has no impact on the timeout signal if it hasn't already been triggered.
// signals will still trigger once the timeout completes.
// if signals has already been triggered, and both of the followed signals
// have either been canceled or triggered already, then signals will never
// trigger again after reset.
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1082#issuecomment-1200226120
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1082/1200226120@github.com>