Ready for Trial: scheduler.yield()

48 views

Skip to first unread message

Scott Haseley

unread,

Apr 5, 2023, 8:07:33 PM4/5/23

to blink-dev

Contact emails

shas...@chromium.org

Explainer

https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md

Specification

None

Summary

Provides a method for yielding control to the browser, which can be used to break up long tasks. Awaiting the promise returned by scheduler.yield() causes the current task to yield, continuing in a new browser task. This can be used to improve responsiveness issues caused by long tasks. Continuations are prioritized to mitigate performance problems of existing alternatives.

Blink component

Blink>Scheduling>APIs

TAG review

Early design review: https://github.com/w3ctag/design-reviews/issues/827

TAG review status

Pending

Risks

Interoperability and Compatibility

This is a new feature and will not change existing event loop task scheduling, so the main risk is that other browsers might not implement the feature. There is an interop challenge, however, that comes with prioritization: we want to be specific enough to provide developers guarantees and interoperable implementations, but provide enough scheduling flexibility for UAs (like the HTML specification does with task sources/task queues), which we'll keep in mind while drafting the spec (see also https://github.com/WICG/scheduling-apis/issues/67).

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

Ergonomics

The default use (inserting yield points in long tasks) should enable Chrome to maintain better performance (responsiveness). There is a risk of continuations starving other work, but there are reasonable mitigations, e.g. bounding total of prioritized continuations (see also https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#preventing-task-starvation-by-continuations). This is something we'll be looking for in origin trial feedback.

Activation

The feature would benefit from a polyfill so that tasks still yield in the case the feature is unavailable. The behavior can be approximated by awaiting `scheduler.postTask()` or wrapping `setTimeout(0)` in a promise. The signal inheritance bit [1], however, would need transpilation support to propagate the current signal across async (Promise) boundaries. But developers can alternatively pass the appropriate priority/signal if necessary on browsers that don't support the feature.

[1] https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#priority--abort-propagation-behavior

Security

See https://github.com/WICG/scheduling-apis/blob/main/explainers/yield-and-continuation.md#self-review-questionnaire-security-and-privacy

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Goals for experimentation

Ongoing technical constraints

None

Debuggability

This has basic new-API devtools support. We plan to work with the devtools team to see if we can integrate continuations into the performance panel in some way.