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

> My impression, and maybe I misunderstood, is that in the current proposal all existing task sources are lumped into the "default" prioritized task source, with a global FIFO order imposed on them.

No, that's not the intention. From my [previous reply](https://github.com/w3ctag/design-reviews/issues/338#issuecomment-520571904): "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."

I also mentioned that we are also considering proposing to specify the priorities of certain task sources, so that it's clear how alternative methods of scheduling (e.g. setTimeout) fit into this model, or maybe at least specifying a maximum priority (e.g. setTimeout shouldn't be higher priority than default)? This is about giving developers some scheduling guarantees. Do you think this would be too rigid as well?

(I'll also update the explainer to clarify this.)

> If the intent is that this is not the case, and that the prioritized task sources are just adding _new_ task sources, that are unordered wrt each other and with existing task sources, then that eliminates my concerns about the system being too rigid.
> 
> That said, it's also not clear to me whether "high priority" means "will run before anything that's low priority" or "will run with higher probability" or something else, or whether this will be up to browsers.

Our current thinking is that the order that prioritized tasks run should be specified, rather than left up to browsers.  We aren't absolutely certain what that behavior should be yet, but we have some initial thoughts. 

The approach we’re experimenting with is that tasks are run in strict priority order, from highest to lowest. This obviously runs the risk of starving lower priority tasks, but task priorities can be dynamically changed by client code so that starvation-prevention can be implemented in userspace, for whatever fits application requirements (which varies, from what we’ve seen).

The appeal of this approach is that it is simple for developers to reason about, both from a correctness and performance standpoint, since (their) high priority work is guaranteed to run before low priority work.

We could also add native platform-exposed support for starvation-prevention, like timeouts or aging. There's some concern, however, about deadline interchange accidentally starving actual high priority work and degrading the user experience.

If the motivation for wanting flexibility of ordering these prioritized task sources (and please correct me if I'm wrong) is to prevent starvation of lower priority work, I think there's a question of where starvation-prevention should be implemented, by browsers or app developers? We've been siding on the developer side in this case since they better know their app requirements, but I think this is a difficult question.

-- 
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-538579860