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