Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AbortSignal.any() #166

Closed
shaseley opened this issue Apr 11, 2023 · 1 comment
Closed

AbortSignal.any() #166

shaseley opened this issue Apr 11, 2023 · 1 comment
Assignees
Labels
from: Google Proposed, edited, or co-edited by Google. position: support topic: dom Spec relates to DOM (Document Object Model) topic: javascript Spec relates to the JavaScript programming language topic: performance venue: none / personal repository The venue for discussion is a GitHub repository not affiliated with a standards body. venue: WHATWG DOM Workstream
Milestone

Comments

@shaseley
Copy link

WebKittens

@annevk

Title of the spec

AbortSignal.any()

URL to the spec

whatwg/dom#1152

URL to the spec's repository

https://github.com/whatwg/dom

Issue Tracker URL

https://github.com/shaseley/abort-signal-any/issues

Explainer URL

https://github.com/shaseley/abort-signal-any

TAG Design Review URL

w3ctag/design-reviews#737

Mozilla standards-positions issue URL

mozilla/standards-positions#774

WebKit Bugzilla URL

No response

Radar URL

No response

Description

AbortSignal.any(signals) returns an AbortSignal that is aborted when any of the source signals are aborted. Developers can use this to combine independent abort sources, e.g. timeouts specified with AbortSignal.timeout() and signals associated with user input, and pass them to async APIs like fetch().

Memory management: composite signals (those returned by this API) must be kept alive while they can be aborted (by one of the sources) and have registered 'abort' event listeners or pending abort algorithms (see GC note in the spec PR). Implementing this API in userland has proved difficult to do without leaks, e.g. because of lack of knowledge about pending abort algorithms, but can be done by the browser where we have more visibility.

To implement the memory management in Chromium, we needed to clean up handling of pending abort algorithms, specifically making sure they get removed when they can no longer have an effect (e.g. when all related fetch state has been GCed). See also this issue.

@hober hober added topic: javascript Spec relates to the JavaScript programming language topic: dom Spec relates to DOM (Document Object Model) venue: WHATWG DOM Workstream venue: none / personal repository The venue for discussion is a GitHub repository not affiliated with a standards body. from: Google Proposed, edited, or co-edited by Google. topic: performance labels Apr 26, 2023
@annevk
Copy link
Contributor

annevk commented Apr 28, 2023

This is a good idea and increases symmetry between abort signals and promises. I suggest we mark this as "position: support" one week from now.

cc @cdumez @weinig

@hober hober added this to the 2023 Week 18 milestone Apr 28, 2023
@annevk annevk closed this as completed Jun 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
from: Google Proposed, edited, or co-edited by Google. position: support topic: dom Spec relates to DOM (Document Object Model) topic: javascript Spec relates to the JavaScript programming language topic: performance venue: none / personal repository The venue for discussion is a GitHub repository not affiliated with a standards body. venue: WHATWG DOM Workstream
Development

No branches or pull requests

3 participants