Bringing setTimeout to ECMAScript
bradley.meck at gmail.com
Sun Mar 20 12:11:29 PDT 2011
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 ?
> 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.
>> 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:
>>>> 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.
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
More information about the es-discuss