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() #774

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

AbortSignal.any() #774

shaseley opened this issue Apr 11, 2023 · 1 comment

Comments

@shaseley
Copy link

Request for Mozilla Position on an Emerging Web Specification

Other information

  • Memory management
    • Composite signals (those created by this API) need to be kept alive as long as they can be aborted and have 'abort' event listeners or pending abort algorithms (the spec PR has a note about this). As part of implementing this In Chromium, we needed to make sure abort algorithms were being removed when they were longer needed, e.g. when all fetch state is GCed and the signal can no longer affect the fetch or response. See also this issue.
  • Early TAG Review: Design review: AbortSignal.any() w3ctag/design-reviews#737
  • Integration with Scheduling APIs
    • As mentioned in the explainer, there's a specialization for TaskSignal.any() so the returned signal also has priority. The draft spec PR is here, which mirrors the DOM PR.
@smaug----
Copy link
Collaborator

I think this looks very reasonable, useful small addition to an existing API.
The pr has possibly just very minor issues.
I'd say we could be positive about this.

(TaskSignal.any is then different topic, since it is still a bit unclear whether Scheduler API is useful.)

@zcorpan zcorpan closed this as completed Apr 13, 2023
@zcorpan zcorpan changed the title Request for Mozilla Position: AbortSignal.any() AbortSignal.any() Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants