[ScriptYielding] setImmediate clamping returns.

Hi,

I've been discussing setImmediate recently in various places and been 
told that here would be the most appropriate place [1], so here I am :-)

I have read through the archives of this list and couldn't find all the 
answers to my questions/concerns.

First off, something is not entirely clear to me. I've just been pointed 
out by John-David Dalton [2] to a page [3] that suggests that the 
current HTML5 "250 callbacks per second" is a madness that drains battery:
"Browsers have attempted to increase the number of callbacks per second 
that JavaScript developers can receive through the setTimeout and 
setInterval API’s (...) preventing hardware from entering low power states."
This suggests that running more callbacks per second is detrimental to 
battery
On the other hand, setImmediate suggests that the callback should be run 
as fast as possible. It's also been said on this list [4] that Microsoft 
doesn't think setImmediate should be clamped (because that would result 
in less callbacks calls per seconds).
Which one do we want for setImmediate? More or less callbacks per seconds?

I would like to discuss the idea of clamping.
Firefox [5] once had a case of a website doing in essence:
(function f(){ setTimeout(f, 0); })();
And that would make the CPU go to 100%.
Their response was to align to what other browsers were doing which was 
to reinterpret "0" as something a bit higher (10ms at the time).
10ms was later changed to 4ms and only for deeply-nested setTimeouts 
(so, setTimeout(f,0) really means 0 until you've done it 4 times in a 
row after which there is the minimum 4ms delay).

The bug that was reported against Firefox, was found somewhere else too 
[6], so (function f(){ setTimeout(f, 0); })(); is something write. Not 
these exact characters, not intentionally, but they write it and, 
unclamped, that uses the CPU 100%. I would be interested to know what is 
expected to happen for
(function f(){ setImmediate(f); })();
It's been suggested [4] that clamping is not an option. And that 
differentiates setImmediate from setTimeout.
Now, Adam Barth suggested [6] that if a browser implements a clamping 
for setImmediate, then, websites with the (function f(){ 
setImmediate(f); })(); mistake would eat less battery in this browser 
and users would be incentivized to use it instead of 
non-setImmediate-clamping browsers. We all know that the natural 
consequence is all browsers moving to the clamping behavior, having to 
de facto standardize that behavior and effectively making setImmediate 
nothing but a setTimeout 0 equivalent.
How can this situation be avoided? (given the current setImmediate spec, 
I can't see how)

Thanks,

David

[1] https://twitter.com/getify/status/365800931176095746
[2] https://twitter.com/jdalton/status/367038319151955968
[3] 
http://ie.microsoft.com/testdrive/Performance/setImmediateSorting/Default.html
[4] http://lists.w3.org/Archives/Public/public-web-perf/2011Jul/0012.html
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=123273
[6] see [4] at the end of 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/Hn3GxRLXmR0/XP9xcY_gBPQJ
[7] 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/Hn3GxRLXmR0/P9zOB1HIQ4IJ

Received on Monday, 12 August 2013 22:51:42 UTC