-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
[dom] Implement AbortSignal.any() prototype #37434
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wpt-pr-bot
approved these changes
Dec 9, 2022
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The review process for this patch is being conducted in the Chromium project.
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-3703640
branch
3 times, most recently
from
December 20, 2022 03:57
77d02fd
to
9d959cc
Compare
This adds the basic functionality for AbortSignal.any(), which creates a new signal that will be aborted if any of the signals associated signals are aborted. The API is implemented behind a flag. The general idea and concepts are: - A signal created with this API is a "composite signal", composed of 0 or more "abort sources". - An abort source can be any AbortSignal, but since the relationships are established at signal creation time, we can link to non-composite signals, i.e. those associated with a controller. - If any of the abort sources are already aborted when this API is called, it returns an aborted signal (with the culprit's reason). - During SignalAbort, a signal will invoke SignalAbort on all of its "dependent signals" (those for which it is a source). Most of this is implemented by AbortSignalCompositionManager. In this CL this class handles linking source/dependent abort signals, but in follow-up CLs this will also: 1. Also manage priority sources for composite TaskSignals, which are created by a specialization for TaskSignal.any(). The logic for managing abort and priority sources/dependents is the same, so this setup is optimized for code reuse. Note also that the WPT tests for for AbortSignal.any() are implemented in resources/ and pulled in via META statements for reuse with TaskSignal.any(). 2. Handle more complex memory management. Memory leaks can result from composite signals following long-lived top-level signals, which we expect to be a common pattern and part of the motivation for the UA maintaining the signal relationships. This is separated out to keep CLs smaller. Explainer: https://github.com/shaseley/abort-signal-any I2P: https://groups.google.com/a/chromium.org/g/blink-dev/c/FSH6hrJMaxM/m/Ft8KiGlbAAAJ Design doc: https://docs.google.com/document/d/1LvmsBLV85p-PhSGvTH-YwgD6onuhh1VXLg8jPlH32H4/edit?usp=sharing Bug: 1323391 Change-Id: Ibc85815b166fd4242543f30600be99fadf35992e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3703640 Reviewed-by: Nate Chapin <japhet@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Commit-Queue: Scott Haseley <shaseley@chromium.org> Cr-Commit-Position: refs/heads/main@{#1089752}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-3703640
branch
from
January 6, 2023 16:59
9d959cc
to
be03e1d
Compare
This was referenced May 1, 2023
annevk
pushed a commit
to whatwg/dom
that referenced
this pull request
May 17, 2023
- This implements an optimization that puts all children on non-dependent signals (i.e., those associated with a controller). This allows "intermediate" nodes (e.g., B in A follows B follows C) to be garbage collected if they are being kept alive to propagate aborts. - This removes the follow algorithm, so callsites will need to be updated. - 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 members specify a realm. Follow-up PRs: - whatwg/fetch#1646 - w3c/ServiceWorker#1678 - whatwg/streams#1277 This also sets the stage to make AbortSignal's "signal abort" fully internal. #1194 tracks the remainder. Tests: web-platform-tests/wpt#37434 and web-platform-tests/wpt#39785. Fixes #920.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds the basic functionality for AbortSignal.any(), which creates
a new signal that will be aborted if any of the signals associated
signals are aborted. The API is implemented behind a flag.
The general idea and concepts are:
0 or more "abort sources".
are established at signal creation time, we can link to non-composite
signals, i.e. those associated with a controller.
called, it returns an aborted signal (with the culprit's reason).
"dependent signals" (those for which it is a source).
Most of this is implemented by AbortSignalCompositionManager. In this CL
this class handles linking source/dependent abort signals, but in
follow-up CLs this will also:
Also manage priority sources for composite TaskSignals, which are
created by a specialization for TaskSignal.any(). The logic for
managing abort and priority sources/dependents is the same, so this
setup is optimized for code reuse. Note also that the WPT tests for
for AbortSignal.any() are implemented in resources/ and pulled in
via META statements for reuse with TaskSignal.any().
Handle more complex memory management. Memory leaks can result from
composite signals following long-lived top-level signals, which we
expect to be a common pattern and part of the motivation for the UA
maintaining the signal relationships. This is separated out to keep
CLs smaller.
Explainer: https://github.com/shaseley/abort-signal-any
I2P: https://groups.google.com/a/chromium.org/g/blink-dev/c/FSH6hrJMaxM/m/Ft8KiGlbAAAJ
Design doc: https://docs.google.com/document/d/1LvmsBLV85p-PhSGvTH-YwgD6onuhh1VXLg8jPlH32H4/edit?usp=sharing
Bug: 1323391
Change-Id: Ibc85815b166fd4242543f30600be99fadf35992e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3703640
Reviewed-by: Nate Chapin <japhet@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1089752}