Remove scheduler.yield() parameters #100
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
By default, scheduler.yield() continuations inherit the priority and abort signal from the current task, but this behavior can be overridden by providing a signal or priority option. But it's not clear if this is necessary, and there are questions around the expectations of subsequent continuations (see WICG#96). To simplify the API, for now we're removing the yield() parameters, instead always using the inherited state. We can revisit this as use cases arise.
mmocny
approved these changes
Aug 6, 2024
There was a problem hiding this comment.
Change is fine, but will repeat the question from other code review, here:
Is it still possible for "inherit" part of the scheduling options via the postTask API? Should it be?
I don't mind that you cannot control changes via yield() since I don't think you need continuation semantics if you are making changes to priority/signal. But it seems very likely useful to be able to only change one part of the options at a time-- and especially the ability to change priority without changing signal.
An alternative option would be for the developer to just keep a reference to the signal -- or if there was an API to expose a reference to the current signal.
Then, rather than adding the option to "inherit", you would just pass the same reference?
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Aug 6, 2024
By default, scheduler.yield() continuations inherit the priority and abort signal from the current task, but this behavior can be overridden by providing a signal or priority option. But it's not clear if this is necessary, and there are questions around the expectations of subsequent continuations (see WICG/scheduling-apis#96). So to simplify the API and prevent shipping behavior we might regret, we're removing the yield() parameters. If control over a continuation's priority/abort is needed, a new task can be scheduled using postTask(). We plan to reevaluate this as the API rolls out and developers start using it in more complex ways. Related PR: WICG/scheduling-apis#100. Bug: 40633887 Change-Id: I5e23c9c8cf950cec795cddafd27c962b71eea5f7
clelland
approved these changes
Aug 7, 2024
Currently not without passing around a signal/priority. I think we could revisit |
aarongable
pushed a commit
to chromium/chromium
that referenced
this pull request
Aug 8, 2024
By default, scheduler.yield() continuations inherit the priority and abort signal from the current task, but this behavior can be overridden by providing a signal or priority option. But it's not clear if this is necessary, and there are questions around the expectations of subsequent continuations (see WICG/scheduling-apis#96). So to simplify the API and prevent shipping behavior we might regret, we're removing the yield() parameters. If control over a continuation's priority/abort is needed, a new task can be scheduled using postTask(). We plan to reevaluate this as the API rolls out and developers start using it in more complex ways. Related PR: WICG/scheduling-apis#100. Bug: 40633887 Change-Id: I5e23c9c8cf950cec795cddafd27c962b71eea5f7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5753325 Commit-Queue: Scott Haseley <[email protected]> Reviewed-by: Michal Mocny <[email protected]> Cr-Commit-Position: refs/heads/main@{#1338805}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Aug 8, 2024
By default, scheduler.yield() continuations inherit the priority and abort signal from the current task, but this behavior can be overridden by providing a signal or priority option. But it's not clear if this is necessary, and there are questions around the expectations of subsequent continuations (see WICG/scheduling-apis#96). So to simplify the API and prevent shipping behavior we might regret, we're removing the yield() parameters. If control over a continuation's priority/abort is needed, a new task can be scheduled using postTask(). We plan to reevaluate this as the API rolls out and developers start using it in more complex ways. Related PR: WICG/scheduling-apis#100. Bug: 40633887 Change-Id: I5e23c9c8cf950cec795cddafd27c962b71eea5f7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5753325 Commit-Queue: Scott Haseley <[email protected]> Reviewed-by: Michal Mocny <[email protected]> Cr-Commit-Position: refs/heads/main@{#1338805}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this pull request
Aug 8, 2024
By default, scheduler.yield() continuations inherit the priority and abort signal from the current task, but this behavior can be overridden by providing a signal or priority option. But it's not clear if this is necessary, and there are questions around the expectations of subsequent continuations (see WICG/scheduling-apis#96). So to simplify the API and prevent shipping behavior we might regret, we're removing the yield() parameters. If control over a continuation's priority/abort is needed, a new task can be scheduled using postTask(). We plan to reevaluate this as the API rolls out and developers start using it in more complex ways. Related PR: WICG/scheduling-apis#100. Bug: 40633887 Change-Id: I5e23c9c8cf950cec795cddafd27c962b71eea5f7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5753325 Commit-Queue: Scott Haseley <[email protected]> Reviewed-by: Michal Mocny <[email protected]> Cr-Commit-Position: refs/heads/main@{#1338805}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this pull request
Aug 9, 2024
…) parameters, a=testonly Automatic update from web-platform-tests Scheduling APIs: Remove scheduler.yield() parameters By default, scheduler.yield() continuations inherit the priority and abort signal from the current task, but this behavior can be overridden by providing a signal or priority option. But it's not clear if this is necessary, and there are questions around the expectations of subsequent continuations (see WICG/scheduling-apis#96). So to simplify the API and prevent shipping behavior we might regret, we're removing the yield() parameters. If control over a continuation's priority/abort is needed, a new task can be scheduled using postTask(). We plan to reevaluate this as the API rolls out and developers start using it in more complex ways. Related PR: WICG/scheduling-apis#100. Bug: 40633887 Change-Id: I5e23c9c8cf950cec795cddafd27c962b71eea5f7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5753325 Commit-Queue: Scott Haseley <[email protected]> Reviewed-by: Michal Mocny <[email protected]> Cr-Commit-Position: refs/heads/main@{#1338805} -- wpt-commits: edcaaa246cdce621e114ef5bb963296457521bab wpt-pr: 47481
ErichDonGubler
pushed a commit
to erichdongubler-mozilla/firefox
that referenced
this pull request
Aug 19, 2024
…) parameters, a=testonly Automatic update from web-platform-tests Scheduling APIs: Remove scheduler.yield() parameters By default, scheduler.yield() continuations inherit the priority and abort signal from the current task, but this behavior can be overridden by providing a signal or priority option. But it's not clear if this is necessary, and there are questions around the expectations of subsequent continuations (see WICG/scheduling-apis#96). So to simplify the API and prevent shipping behavior we might regret, we're removing the yield() parameters. If control over a continuation's priority/abort is needed, a new task can be scheduled using postTask(). We plan to reevaluate this as the API rolls out and developers start using it in more complex ways. Related PR: WICG/scheduling-apis#100. Bug: 40633887 Change-Id: I5e23c9c8cf950cec795cddafd27c962b71eea5f7 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5753325 Commit-Queue: Scott Haseley <[email protected]> Reviewed-by: Michal Mocny <[email protected]> Cr-Commit-Position: refs/heads/main@{#1338805} -- wpt-commits: edcaaa246cdce621e114ef5bb963296457521bab wpt-pr: 47481
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.
By default, scheduler.yield() continuations inherit the priority and abort signal from the current task, but this behavior can be overridden by providing a signal or priority option. But it's not clear if this is necessary, and there are questions around the expectations of subsequent continuations (see #96).
To simplify the API, for now we're removing the yield() parameters, instead always using the inherited state. We can revisit this as use cases arise.
Preview | Diff