Re: setImmediate should allow the UA to delay the event

I believe the intent is that setImmediate() is not clamped even when nested,
unlike setTimeout(..., 0). Jason, did you intend to specify that
setImmediate() callbacks use the timer task queue or a different one? Your
draft does not specify any task source at all.

- James
On Jun 30, 2011 12:33 AM, "Ian Hickson" <ian@hixie.ch> wrote:
> On Thu, 30 Jun 2011, Boris Zbarsky wrote:
>>
>> Both setTimeout and setInterval have this step in their processing:
>>
>> * Optionally, wait a further user-agent defined length of time.
>>
>> I believe it would be a good idea to have this for setImmediate as well.
>> In Gecko's implementation, we are considering introducing a delay into
>> setImmediate invocations in background tabs, minimized windows, etc. Not
>> as much of a delay as setTimeout/setInterval are getting, but some
>> delay.
>>
>> Note that as long as you only examine setImmediate this is not black-box
>> distinguishable from throttling the entire event queue for the relevant
>> browsing context. You can only tell the difference by comparing order
>> of setImmediate invocation with other events in the event queue.
>
> What's the difference between setImmediate() and setTimeout(..., 0)?
>
> Is it just that it uses a different task source? (i.e. can be prioritised
> differently relative to setTimeout() calls by the event loop?)
>
> --
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>