Intent to Implement: Main thread Scheduling APIs: Prioritized scheduler.postTask

[Scott Haseley]

Contact emails

shas...@chromium.org, pani...@chromium.com Explainer https://github.com/WICG/main-thread-scheduling/blob/master/PrioritizedPostTask.md Design docs/spec https://docs.google.com/document/d/1xU7HyNsEsbXhTgt0ZnXDbeSXm5-m5FzkLJAT6LTizEI/edit TAG review https://github.com/w3ctag/design-reviews/issues/338 Summary The scheduler.postTask() API allows developers to schedule tasks at a given priority through a native scheduler. This API also allows developers to create custom prioritized TaskQueues to manage groups of tasks. Motivation It is too difficult to build web apps that are responsive to user interaction, and that remain responsive over time. Script is a primary culprit that hurts responsiveness. Consider a "search-as-you-type" application: this app needs to be responsive to user input i.e. user typing in the search-box. At the same time any animations on the page must be rendered smoothly, as well as the work for fetching, preparing and displaying search results must progress quickly. This problem can be tackled by systematically chunking and scheduling main thread work, i.e. prioritizing and executing work async at an appropriate time relative to current situation of user and browser. Userspace schedulers exist for this purpose, and use priority to order execution of their tasks. But this priority has limited meaning since they do not control all tasks on the page. Apps can consist of 1P, 1P library, 3P, and (one or more) framework scripts, all of which compete for the main thread. At the same time, the browser has tasks to run on the main thread, such as async work (e.g. fetch() and IDB tasks) and garbage collection. The problem is that most of these tasks run at the same priority, as the Platform only exposes a few priorities, either explicitly or implicitly through a disparate set of APIs. And without sufficient priorities, the browser is limited in how it can schedule tasks.

Link to previous related "Intent to Implement" https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/eLq8t56CbaQ/Ik7vP__GBgAJ

Risks

Interoperability and Compatibility If other browsers do not implement the APIs, the situation is no worse than today; it will be possible to feature detect and take advantage of improved scheduling on browsers that do ship the API. This API was discussed at a recent WebPerf WG F2F. The overall sentiment was positive, especially from developers present at the meeting. Browser vendors appear generally cautious, but supportive. Firefox: No public signals Edge: No public signals Safari: Mixed public signals Priority inversion and dependency tracking are concerns. We plan to flesh these concerns out and address them as the API progresses. Web developers: Strongly positive Positive feedback at a recent WebPerf WG F2F. We are also closely working with React, Google Maps, and Airbnb, who are strongly positive about the API. Ergonomics Could the default usage of this API make it hard for Chrome to maintain good performance? Unlikely. There is always concern around starvation and abuse when introducing (higher) priorities. But it is always a possibility that script just won't yield (or queue microtasks, or abuse rAF) -- which are as high or higher than priorities we are planning to introduce. We will continue, however, to think about abuse and mitigation as we develop the API. Activation Will it be challenging for developers to take advantage of this feature immediately, as-is? No. Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use? Likely.

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? No Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/6031161734201344

This intent message was generated by Chrome Platform Status.

[Boris Zbarsky]

On 7/31/19 12:46 PM, Scott Haseley wrote:
> Interoperability and Compatibility If other browsers do not implement
> the APIs, the situation is no worse than today; it will be possible to
> feature detect and take advantage of improved scheduling on browsers
> that do ship the API.

It seems like the main challenge here is defining an API that is both
useful to authors and does not assume too much about scheduling
implementation details in browsers, right?

-Boris

[Philip Jägenstedt]

That indeed seems like a challenge. Just as a quick check, do the
colored figures in
https://github.com/WICG/main-thread-scheduling/blob/master/PrioritizedPostTask.md
line up with what could be implemented in Gecko? That the categories
in the first exist seems like a given, but are there internal details
of scheduling that would be at odds with the proposed setup in the
second figure?

https://github.com/w3ctag/design-reviews/issues/338 also seems like a
good place to raise issues like this.

[Boris Zbarsky]

On 8/1/19 4:56 AM, Philip Jägenstedt wrote:
> That indeed seems like a challenge. Just as a quick check, do the
> colored figures in
> https://github.com/WICG/main-thread-scheduling/blob/master/PrioritizedPostTask.md
> line up with what could be implemented in Gecko? That the categories
> in the first exist seems like a given

Sort of. In practice things in the "inter-frame" bucket don't all run
at the same priority in all cases and the scheduling of
requestAnimationFrame (and its relative priority wrt other things)
differs in different browsers and situations. That's off the top of my
head; there might be more complications there.

> but are there internal details
> of scheduling that would be at odds with the proposed setup in the
> second figure?

As far as I can tell, the proposed setup of the second figure _requires_
that:

1) The set of internal priorities exactly match this figure.
2) There is a single FIFO queue per priority shown in the figure.

In particular, it completely overrides the HTML spec concept of
independently-schedulable task sources, as far as I can tell.

There's the additional complication that the HTML task sources are
specced to be order-preserving in a document-spanning way and at the
same time the new FIFO queues are defined to be order-preserving in a
limited-to-document way. There's a good chance that between those two
requirements you end up imposing a global order on pretty much
everything that shares a given event loop...

In terms of the specific question about Gecko, we are in the middle of
experimenting with and evaluating a number of possible scheduling
changes. I believe most of them are not compatible with the proposal's
FIFO-per-priority-defined-in-this-document model, because that model
seems pretty rigid in terms of what it allows in terms of the UA
prioritizing the things at "normal" priority, which is the vast majority
of what's going on, against each other.

> https://github.com/w3ctag/design-reviews/issues/338 also seems like a
> good place to raise issues like this.

I commented there, thank you.

-Boris

[Scott Haseley]

Hi Boris, 

Thanks for raising this concern; I've replied on the GitHub thread.

 - Scott