bruant.d at gmail.com
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 gmail.com> 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:
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 
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