David Bruant bruant.d at
Thu Aug 8 13:26:49 PDT 2013

Le 08/08/2013 22:04, Jason Orendorff a écrit :
> On Thu, Aug 8, 2013 at 9:40 AM, David Bruant <bruant.d at> 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.



More information about the es-discuss mailing list