Re: [spec-reviews] requestIdleCallback (#70)

On Friday 2015-10-23 12:09 +0900, L. David Baron wrote:
> 1. Does the spec's notion of "idle" scale well to a more multi-core future in which browsers do a good job of taking advantage of those cores?  In particular, engines may be moving to doing more tasks (e.g., beyond compositing to tasks that are more part of layout or even style computation) on other threads, or (probably less worrysome here) dividing a main-thread-blocking task across multiple threads to help it finish faster.  I tend to think the APIs are probably ok in that regard, given that they're a relatively straightforward extension of setTimeout, but I'm a little more worried about the prose (both the diagrams of how things work in section 2 and the processing model in section 5 -- see the next point).

Perhaps a slightly better concrete example for this concern: suppose that an implementation wants some work that doesn't block the main thread's event loop to still make things count as "not idle", so that the idle callback work doesn't detract from that work happening on other threads.  One could interpret the first paragraph of the processing model section of the spec as disallowing such consideration ("assesses that a given event loop is likely to remain idle for a non-trivial amount of time"), but I think considering such things should be allowed.


---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/70#issuecomment-150448636