Are equal timeouts executed in order in Javascript?

Suppose I do

setTimeout(foo, 0);

...

setTimeout(bar, 0);

Can I be sure foo will begin executing before bar? What if instead of 0 I use a timeout of 1, 10, or 100 for bar?

Simple experiments show that in the case of equal timeout values the timeout targets are executed in the same order as the setTimeout开发者_如何转开发s themselves, but is it safe to rely on this behavior?

It is not safe to rely on this behavior. I wrote a test script which schedules a number of functions (and they in turn also schedule a number of functions) all using setTimeout(..., 0), and the order in which the functions were called was not always the same as the order in which setTimeout was called (at least in Chrome 11, which I used to run the script).

You can see/run the script here: http://jsfiddle.net/se9Jn/ (the script uses YUI for cross-browser compatibility, but Y.later uses setTimeout internally).

Note that if you just run the script and stare at the console, you will probably not see an offending ordering. But if start the script, switch to another tab, load some pages, and come back to the test page, you should see errors about callbacks out of order in the console.

If you need a guaranteed ordering, I would recommend scheduling the next function at the end of the previous function:

setTimeout(foo, 0);

...

function foo() {

    ...

    setTimeout(bar, 0);
}

I read through the Firefox source code, and at least for that browser, there is a sequentiality guarantee for timeouts which are specified in nondecreasing order. Otherwise all bets are off.

Specifically, if in a given execution context you set a timeout for n, and then one for m, where n <= m, the targets will be executed in the order the timeouts were set.

But don't take my word for it. I believe the window implementation is in nsGlobalWindow.cpp, and the method which actually decides where timeouts go in the execution queue is called InsertTimeoutIntoList. It looks like the method traverses the queue backwards looking for the first timeout which is less than or equal to the given timeout, and inserts the given timeout after it.

Of course when the timeout is set the current clock time is added to the timeout value. This is why the timeout values must be in nondecreasing order for the targets to be executed in sequence.

The answer is: No, execution order is not guaranteed. I have occasionally seen non-FIFO ordering in chrome 40, especially if I pause in debugger while timeouts are pending. I also had a rare sighting in the wild - it was the only plausible explanation of an incident I investigated.

If you need guaranteed execution order, instead of setTimeout(callback, 0) you can do this:

var queue = [];
function handleQueue() {
    queue.shift()();
}
function queueCallback(callback) {
   queue.push(callback);
   setTimeout(handleQueue, 0);
}

Now, for guaranteed foo, bar order you can:

queueCallback(foo);
...
queueCallback(bar);

In short, don't count on it. Have a look at this.

There's a lot of information in this figure to digest but understanding it completely will give you a better realization of how asynchronous JavaScript execution works.

There is a certain minimum that the delay can actually be, and that depends greatly on the OS, browser, browser activity and computer load. I tend to not go below 20ms as I think anything less than that doesn't make any difference.

When you put two delays that are equal it doesn't necessarily mean that it will happen in that order.

If you want to ensure that it will be done in order I tend to do something like this:

setTimeout(function() { 
  foo();
  setTimeout(bar, 20)
}, 20);

This will always guarantee order.

If you are using Firefox, to ensure your javascript is actually multithreaded you may want to look at the WebWorker, which is supported on the newer browsers, but not IE.