David Herman dherman at
Mon Aug 12 16:58:58 PDT 2013

On Aug 8, 2013, at 2:08 PM, K. Gadd <kg at> wrote:

> Why is the slow script dialog box even relevant for setImmediate? As I understand it, setImmediate is equivalent to DoEvents in Visual Basic/Windows Forms and pumping the message loop in a normal C application. That is, you can use setImmediate to make your application run as fast as possible while still allowing the browser to pump messages, which ensures keyboard/mouse inputs are processed and the window does not get flagged as unresponsive.

Yeah, I'm actually not at all clear which of (at least?) four plausible semantics could be meant by setImmediate:

(a) push a new microtask (to the front of the current microtask list)
(b) enqueue a new microtask (to the back of the current microtask list)
(c) push a new event (to the front of the event queue)
(d) enqueue a new event (to the back of the event queue)

I'd always assumed it meant (d), which seems to me it's "what setTimeout(.., 0) really wanted to be." If people want something for scheduling microtasks I'd think they would still want something for scheduling events.

For the record, my opinions on this whole space are:

- I'm pretty sure we have to leave implementations free to throttle event queues, but current competitive pressure over performance would ensure that a new API would not be as heavily throttled as setTimeout 0.
- Microtasks should not be throttled since they block the event queue.
- Microtasks should be treated the same as ordinary synchronous code.
- I see *no* reasonable alternative to runaway microtask churn other than slow-script dialog.

(Opinions subject to revision yadda yadda yadda.)


More information about the es-discuss mailing list