[whatwg/dom] Add AbortSignal.any() (PR #1152)

<!--
Thank you for contributing to the DOM Standard! Please describe the change you are making and complete the checklist below if your change is not editorial.
-->

Hi DOM folks,

I've got a working implementation of [AbortSignal.any()](https://github.com/shaseley/abort-signal-any) with tentative WPT tests, so I wanted to send out a draft spec for thoughts/consideration. It's probably not ready as-is because it would break other specs (see below), but this is how I thought the end state might look.

### PR Description

This adds IDL and algorithms for [AbortSignal.any()](https://github.com/shaseley/abort-signal-any).

Implementation details:
 - This implements an optimization that puts all children on non-composite signals (i.e. those associated with a controller or timeout). This allows "intermediate" nodes (e.g. B in A follows B follows C) to be garbage collected if they are only being kept alive to propagate aborts.

 - This removes the follow algorithm, so callsites will need to be updated.

 - This makes "signal abort" private. This is done so we can make assumptions about when a signal can no longer abort. The few places that directly signal abort will be converted to use an AbortController (this also exposes an algorithm to "request abort" on a controller for this).

 - The "create a composite abort signal" algorithm takes an interface so that TaskSignal.any() can easily hook into it but create a TaskSignal.

 - Some algorithms that invoke "follow" create an AbortSignal in a particular realm. This enables doing that, but borrows some language from elsewhere in the spec w.r.t. doing the default thing. Neither of the other two static AbortSignal factory APIs specify a realm.

### Dependent / Follow-up work

As-is, this PR changes how other specs would interact with abort signals and controllers. The related work is to:
 1. Don't invoke "signal abort" outside of the DOM spec, use "request abort" on an abort controller instead.
 2. Don't invoke "follow" anywhere, use "create a composite abort signal" instead.
 3. (probably) Make sure algorithms are being removed when they will no longer have an effect, e.g. when the underlying operation is completed or failed.

### Implementation Notes

There's an implementation of this in Chromium behind a flag in Canary (M112). The basic implementation was straightforward, but there was a bit of work to get the memory management implemented (what's described in the Garbage Collection section in the draft PR). Composite signals can't be GCed if they have abort algorithms (or abort event listeners) and there's a source signal that can still signal abort, but we weren't removing abort algorithms once they were "done", which prevented GC. I fixed this in Chromium, but we should probably also update specs too.

### PR Questions

- [ ] At least two implementers are interested (and none opposed):
   * Chromium
   * …
- [ ] [Tests](https://github.com/web-platform-tests/wpt) are written and can be reviewed and commented upon at:
   * https://github.com/web-platform-tests/wpt/commit/e8cba6918a23cc46ebfb7c83c7439f3abc0aa973 (tentative WPT tests)
- [ ] [Implementation bugs](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) are filed:
   * Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1323391

   * Gecko: …
   * WebKit: …
   * Deno (only for aborting and events): …
   * Node.js (only for aborting and events): …
- [ ] [MDN issue](https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests) is filed: …

(See [WHATWG Working Mode: Changes](https://whatwg.org/working-mode#changes) for more details.)

### Additional Info

 - [TAG Review](https://github.com/w3ctag/design-reviews/issues/737) (completed)
You can view, comment on, or merge this pull request online at:

  https://github.com/whatwg/dom/pull/1152


-- Commit Summary --

  * Add AbortSignal.any()

-- File Changes --

    M dom.bs (106)

-- Patch Links --

https://github.com/whatwg/dom/pull/1152.patch

https://github.com/whatwg/dom/pull/1152.diff


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1152

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1152@github.com>