search

w3c / requestidlecallback

Cooperative Scheduling of Background Tasks
https://w3c.github.io/requestidlecallback/
Other
50 stars 19 forks source link

Clarify meaning of "guarantee" for timeout callback #33

Closed Krinkle closed 8 years ago

Krinkle commented 8 years ago

[..] there is no guarantee that a user agent will have any idle CPU time available [..]. it is entirely acceptable that the user agent does not schedule any idle period [..]. In order to provide script authors with a guarantee that these callbacks will be run, authors can specify a timeout [..]

I assume this "guarantee" is relatively weak in that it is subject to:

  1. The page staying open long enough.
  2. No synchronous code running in the main thread preventing the event loop from progressing.

I think point 2 is in the category of "shooting oneself in the foot", but I'm curious about point 1.

I'm not expecting a super strong guarantee since there are always factors that may cause a user agent or device to shutdown beyond the developer's control. But for example, is it expected to run idle work (that has a timeout) when a browser context (e.g. tab) is closed or unloaded?

I'm also curious whether the queue is meant to be preserved in situations like tab restoration (Chrome) and e.g Firefox's BFCache. If I recall correctly they throw away timers and intervals.

dentuzhik commented 8 years ago

Also interested in behavior of execution, when tab is closed. In current chrome dev docs, it's even recommended to use as tool for scheduling sending of analytics data, what actually doesn't play good, if delayed execution is not guaranteed (like in navigator.sendBeacon).

igrigorik commented 8 years ago

@Krinkle apologies about the delay! How about the following...

As such, it is entirely acceptable that the user agent does not schedule any idle period, which would result in the idle callbacks posted via the requestIdleCallback API being postponed for a potentially unbounded amount of time. For cases where the author prefers to execute the callback within an idle period, but needs to place a time bound that it is willing to wait for such period, the author can set the timeout property in the options argument to requestIdleCallback: if the specified timeout is reached before the callback is executed within an idle period, a non-idle task will be queued to execute it.

So, we setup a timer on your behalf and queue a task within it (if it's reached).. As such, I think that also answers your other question about unload and restore: we don't execute all the outstanding timers when unloading, and same applies to rIC. If there are outstanding rIC tasks, regardless of whether they have a timer or not.. they're wont be executed.

In current chrome dev docs, it's even recommended to use as tool for scheduling sending of analytics data, what actually doesn't play good, if delayed execution is not guaranteed (like in navigator.sendBeacon).

Right, this is where you should be using Page Visibility + rIC. Specifically, collect your analytics beacons into a queue and schedule rIC to process them + setup a visibilitychange handler to do the same. If the visibilitychange event fires, check the queue and purge it (i.e. fire sendBeacons) if non-zero.