LGTM to experiment from 115 to 118 inclusive.

On 6/13/23 1:53 PM, Scott Haseley wrote:


        Contact emails

shase...@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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EScheduling%3EAPIs>


        TAG 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).



        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.



        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

The main goal is to evaluate yielding with prioritized continuations on site-specific metrics. More frequent yielding is known to improve responsiveness (should also be measured in experiments), but there's often a cost (latency) to regaining control of the thread. This API prioritizes continuations to mitigate this, and we want to measure the impact on site-specific metrics to evaluate the scheduling behavior.


        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.



        Will this feature be supported on all six Blink platforms
        (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


        Is this feature fully tested by web-platform-tests
        
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

Yes


        DevTrial instructions

https://github.com/WICG/scheduling-apis/blob/main/implementation-status.md


        Flag name

--enable-blink-features=SchedulerYield


        Requires code in //chrome?

False


        Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=979020


        Estimated milestones

OriginTrial desktop last        118
OriginTrial desktop first       115
DevTrial on desktop     113

OriginTrial Android last        118
OriginTrial Android first       115
DevTrial on Android     113

OriginTrial webView last        118
OriginTrial webView first       115



        Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6266249336586240


        Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1SBQP-ABM3%2BsDtKzUZiPoSCWqW2mLOjMrUfFBx4TomSw%40mail.gmail.com

This intent message was generated by Chrome Platform Status <https://chromestatus.com/>.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1Uj8nX5HrUT86iZ83YBj%3D6GJ4jnKZKYF3tOq%3D_twN_Yg%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXGoJ1Uj8nX5HrUT86iZ83YBj%3D6GJ4jnKZKYF3tOq%3D_twN_Yg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/036d1076-0912-4f2d-b341-bd6701602988%40chromium.org.

Reply via email to