Le 08/08/2013 22:04, Jason Orendorff a écrit :
On Thu, Aug 8, 2013 at 9:40 AM, David Bruant <[email protected]> wrote:
Small delays between (micro)task sounds like a local maximum it's hard to
get away from unfortunately :-(
I think I was wrong here when it comes to microtasks.
Microtasks bypass the event queue, so delaying them delays all the other
messages in the queue by definition. Forcing a delay on microtasks means
an irresponsive UI.
What if, instead of a slow script dialog, browsers responded to
microtask/setTimeout(0) abuse with gradual throttling? Well-behaved
applications would get immediate setTimeout(0) callbacks. Badly
behaved applications would run slowly.
That's already the case with setTimeout in a way. Try:
setTimeout(function f(){
setTimeout(f, 0);
}, 0)
You never get the slow script dialog. The 4ms clamping is here to make
that code this code runs yet does not burn the CPU.
Other than that, the browser with the shortest delay wins the battle, I
believe. "my application runs faster in X than in Y" forcing Y to reduce
the delay and align with X.
Now that I think about it, maybe the proposal I made for microtasks [1]
could work for setImmediate. setImmediate would be guaranteed to run
asap (in a different task, not microtask) without clamping.
The mitigation for browsers is possible via kill too-deeply-nested
setImmediates (preferably before running one and not in the middle of
one :-p) and telling the script if it asked to be notified.
That's a version of setImmediate I would agree with as it would be a
significant improvement over what we have today.
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-August/032630.html
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
