It isn't in the past though, it is scheduled to be run as soon as
possible past a certain point. That being said `as soon as possible`
may not be in a particular order (os schedulers / threads / event
listeners in js for example). I view this close to even listeners in
the respect that schedule of events cannot be determined. While it may
appear to be logical to have events FIFO based upon maxage, most other
systems besides a simple manual iteration of a set do not follow this.
I don't schedule events in a particular order because I have never
encountered a situation where I would want 2 timers where I couldn't
schedule the 2nd one that depends upon the first, after the first. Is
there a situation where it makes sense to have
setTimeout(f,10)
setTimeout(g,20)
where g depends f instead of:
setTimeout(function(){
f();
setTimeout(g,10);
},10)
Which is more verbose, but far clearer on intention.
1. This allows for the linear fashion that people may desire, without
causing limiting behavior on the scheduler.
2. This is much more clear that g should fire 10milliseconds after f
rather than possibly immediately after f (which presumably is what the
example wants).
3. It encourages less `magic` in how things are scheduled.
Expectations of manipulation are lowered and code design is encouraged
over engine implementation.
The fact that you say an order should be honored is a bit misleading
for 2 facts.
1. I would expect g to fire 10ms after f, but it may fire immediately.
2. By design it separates the dependent functions f and g so I have no
reason seeing that code to expect g to rely on f.
So while you may see this as being an expectation of FIFO based upon
max age, I merely see it as after x milliseconds something should be
fired, nothing more, no magic.
On Sun, Mar 20, 2011 at 4:34 PM, Jorge <jo...@jorgechamorro.com> wrote:
> 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 <jo...@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 <jo...@jorgechamorro.com> wrote:
>>>>> On 20/03/2011, at 14:00, Wes Garland wrote:
>>>>>
>>>>> On Sun, Mar 20, 2011 at 6:03 AM, Jorge <jo...@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@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>
>>>
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
