Re: [w3ctag/design-reviews] Scheduling APIs (#338)

@bzbarsky Thanks for raising this concern.

Integrating the proposed prioritized task queues with the existing unprioritized task queues is certainly a challenge and is an open question at this point. It is not our goal to remove the ability for UAs to reorder independent task sources, but there is an open question around how prioritized task queues should fit in.

There are a few questions to consider here:

1. How should tasks from prioritized task queues be ordered with respect to each other for task queues created by a specific Scheduler?

   This is all about establishing a priority system for the postTask API, which is a primary goal of the API. There are a lot of options here, many of which are discussed [here](https://docs.google.com/document/d/1AATlW1ohLUgjSdqukgDx3C0P6rnJFgZavmKoZxGb8Rw/edit). We could leave this up to browsers to decide, but this comes at the cost of less developer certainty.

2. How should tasks from all prioritized task queues be ordered with respect to each other, regardless of which Scheduler creates them?

   This is about scoping (1). Should this be global? You bring up a good point that the current spec preserves order across documents that share an event loop, but I worry about things like high priority script on background pages or in off-screen frames, etc. Maybe throttling will suffice here?

3. How should tasks from prioritized task queues and other task queues be ordered?

   As mentioned earlier, it isn’t our goal to limit the ability of UAs to prioritize the various task sources. And IMO one of the biggest open and most important questions of this API is how existing task sources and rendering integrate with respect to tasks in prioritized task queues. For example, do we guarantee that the highest priority (called immediate for now) is render-blocking? What about high priority with respect to timers, or other methods developers currently use to schedule tasks?
  
   Providing developers with some minimum guarantees would lead to more predictable behavior, which is a good thing. At the same time, it’s important to provide flexibility to allow browsers to experiment and optimize performance, and in this case, perhaps alleviate concerns around starvation caused by high priority work.

   Our current thinking here is that speccing the priority of certain task sources, specifically those that are alternatives methods of scheduling (setTimeout/setInterval, potentially postMessage) would be very beneficial to both this API and developers. We would evaluate other task sources in response to developer concern/feedback, and if needed, each resulting in a separate spec change proposal.


We’d be happy to hear any further thoughts you have on this.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/338#issuecomment-520571904