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

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

Yes, with the addition of _maybe_ proposing spec changes to a few existing task sources.
 
> > 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.

Agreed, and I’d be excited to see what browsers find w.r.t. (1) :).
 
> 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.

We expect a small number of libraries (including React) would provide this functionality so not every consumer would need to implement starvation prevention. We've found that different apps have different requirements when it comes to starvation prevention, and want to get more real world experience before baking something into the platform. But, we agree that it will need to be addressed and it's an area that we'll continue to explore.

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