Bringing setTimeout to ECMAScript

Jorge jorge at jorgechamorro.com
Sun Mar 20 14:34:42 PDT 2011


For an event with multiple listeners you can't rely on a certain order because it's spec'ed that you shouldn't.

But given two events of the same kind and a single listener, you'd expect them to be dispatched in order, won't you ?

A timer that times out is an event, and timers in the farther past should timeout before more recent ones. There's an order there that should be honored.
-- 
Jorge.

On 20/03/2011, at 20:11, Bradley Meck wrote:

> If it has been more than 20 milliseconds i expect both of them to be
> able to be fired, so sure. In some ways this is similar how i don't
> rely on the order of event listeners being fired.
> 
> On Sun, Mar 20, 2011 at 10:15 AM, Jorge <jorge at jorgechamorro.com> wrote:
>> Hi Bradley,
>> 
>> So, do you *really* say that given this:
>> 
>> setTimeout(f, 10);
>> setTimeout(g, 20);
>> 
>> you'd be fine with g() being called before f() ? Really ?
>> 
>> Cheers,
>> --
>> Jorge.
>> 
>> On 20/03/2011, at 15:40, Bradley Meck wrote:
>> 
>>> I would just like to state, to me it makes no sense to assume the
>>> order of a timer is guaranteed, if something must happen after
>>> another, you should provides semaphore checks anyway (not real ones,
>>> just a counter to see if the number of tasks done is correct or
>>> flags). This would also help to prevent some odd situations where a
>>> timer generator gets fired twice as well as not limiting timeout for
>>> the more common situation where the order of timers truly does not
>>> matter by forcing a clamping and ordering algorithm.
>>> 
>>> Cheers,
>>> Bradley
>>> 
>>> On Sun, Mar 20, 2011 at 9:30 AM, Jorge <jorge at jorgechamorro.com> wrote:
>>>> On 20/03/2011, at 14:00, Wes Garland wrote:
>>>> 
>>>> On Sun, Mar 20, 2011 at 6:03 AM, Jorge <jorge at jorgechamorro.com> wrote:
>>>>> 
>>>>> will eventually fire g() before f() is nodejs:
>>>>> <https://github.com/joyent/node/pull/604>
>>>>> I've never seen that in any browser.
>>>> 
>>>> This sounds like a bug in Node's clamping algorithm.
>>>> 
>>>> It's not, there's an -unwanted- 1ms clamp, but that's not the problem. It's
>>>> a limitation of the optimizations in place in the implementation of
>>>> setTimeout()/setInterval(). To guarantee the correct order would require a
>>>> less performant implementation.
>>>> --
>>>> Jorge.
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>> 
>>>> 
>> 
>> 



More information about the es-discuss mailing list