For promises using microtasks, one possibility I've been experimenting with in my polyfill is a Promise.yield() method that returns a Promise that resolves after the next time the UI thread gets a chance to drain its event queue (either through requestAnimationFrame or setTimeout).

While it works better with async/await or generators+trampoline, it still works with Promise#then (and Promise#flatMap).  It doesn't prevent developers from writing bad code, but it does provide a way to break out of the microtask scheduler.

Also, unless it breaks an invariant or expectation, would it be useful to have microtasks periodically and/or randomly yield to the event queue to allow the UI to drain its events? There could also be a (albeit probably better named) nextMicrotaskWillYield() API that could be called to have some foreknowledge as to whether future microtasks scheduled within the current microtask will be delayed until after the browser can process tasks or the event queue.

Ron

Sent from my Windows Phone
________________________________
From: Jorge Chamorro<mailto:jorge at jorgechamorro.com>
Sent: ‎8/‎9/‎2013 9:50 AM
To: David Bruant<mailto:bruant.d at gmail.com>
Cc: EcmaScript<mailto:es-discuss at mozilla.org>
Subject: Re: setImmediate

On 08/08/2013, at 15:55, David Bruant wrote:

> This is not a "Trying to protect us from ourselves" situation. This is a "browser trying to protect users from any sort of abuse" situation. For while loops, they implemented the "script takes too long" dialog. For mistakenly infinitely nested too short setTimeouts, they implemented 4ms clamping.
> If browsers can't have mitigation strategies when features are abused, we will run in the same situations than before.
>
> As a JS dev, I want the same features than you. Now, how do browsers make sure this doesn't drain users battery in case of misuse? (I don't have an answer yet)

I think that it can't be avoided. A program, in the middle a longish operation, *must* yield to the event loop to avoid events starvation and/or to force redraws, so there *must* be a way to do so, and it *must* be *fast* (without 4ms clampings).

Yes, there are malicious sites and there are silly programmers to drain your batteries, but there are also 100% legit reasons to spin the event loop...

I would put in the browsers a cpu hog/battery drain dial/indicator per page, so that the users could at least see it and act accordingly (they'll soon learn why that's important).

I for one have already uninstalled lots of iPhone apps, just because they drained my batteries too fast.

Also, the original "classic" MacOS had an EventAvail() call to let the program know if there were any events pending, in a program in a busy loop this helps decide whether it's time to yield or not.
--
( Jorge )();
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130809/ff332000/attachment.html>

For promises using microtasks, one possibility I've been experimenting with in my polyfill is a Promise.yield() method that returns a Promise that resolves after the next time the UI thread gets a chance to drain its event queue (either through requestAnimationFrame or setTimeout).

While it works better with async/await or generators+trampoline, it still works with Promise#then (and Promise#flatMap).  It doesn't prevent developers from writing bad code, but it does provide a way to break out of the microtask scheduler.

Also, unless it breaks an invariant or expectation, would it be useful to have microtasks periodically and/or randomly yield to the event queue to allow the UI to drain its events? There could also be a (albeit probably better named) nextMicrotaskWillYield() API that could be called to have some foreknowledge as to whether future microtasks scheduled within the current microtask will be delayed until after the browser can process tasks or the event queue.