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

> The approach we’re experimenting with is that tasks are run in strict priority order, from highest to lowest.

So just to make sure I understand the proposal:

1) This applies to the tasks that userspace (i.e. web page) code has queued via the prioritized task system.
2) It does not apply to specification-defined tasks (at least existing ones; future specs may want to use the prioritized task setup).  These can be scheduled by the browser in any desired way around the explicitly-prioritized tasks, and the browser is responsible for preventing starvation.

> 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

Just to be clear, I think we need flexibility in the following:

1) Ordering various existing task sources against each other.  There is ongoing research in browsers on the best way to do that, and I don't think we're at a point where we can say what works best here and pin it down.
2) Preventing of starvation of browser-generated tasks of various sorts.  Developers may not know what these all are and while some of them might be low-priority when initially queued that doesn't mean they're infinitely-starvable.  Maybe this can be represented as priority changes, or maybe it gets represented by schedulers that prevent indefinite starvation, but fundamentally the client code doesn't have enough information to know whether starving specific non-client tasks is OK or not, and we shouldn't allow it do to that.

I don't have strong views about how starvation-prevention should work for userspace-generated prioritized tasks, but I _would_ like to suggest that writing a userspace starvation-preventer is all fine and dandy for a Google or a Facebook that completely controls all the code on a page, but expecting every single consumer of the API to do it is a bit of a red flag for me, when the typical consumer of the API might just be someone who includes a few different libraries in whatever their website is, then ends up with those libraries all using this system independently and not playing well together.  At that point there is no way for them to fix the problem, really, and I'm not sure the "they better know their app requirements" condition holds either.

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