Why does the Javascript EventLoop have different result？

Question

Recently, I read an article about Javascript EventLoop. But when I put the code into Visual Studio Code for execution, there are some different result. I'm confused. Thanks for help!

Here is the code:

console.log('1');

// written as set1
setTimeout(function () {
    console.log('2');
    // written as set4
    setTimeout(function() {
        console.log('3');
    });
    // written as pro2
    new Promise(function (resolve) {
        console.log('4');
        resolve();
    }).then(function () {
        console.log('5')
    })
})

// written as pro1
new Promise(function (resolve) {
    console.log('6');
    resolve();
}).then(function () {
    console.log('7');
    // written as set3
    setTimeout(function() {
        console.log('8');
    });
})

// written as set2
setTimeout(function () {
    console.log('9');
    // written as pro3
    new Promise(function (resolve) {
        console.log('10');
        resolve();
    }).then(function () {
        console.log('11');
    })
})

The result could be one of the following:

1,6,7,2,4,9,10,8,5,11,3

1,6,7,2,4,9,10,5,11,8,3

As I think,when a setTimeout is done,the javascript should go to handle the micro-task like Promise;But after set1,it goes to set2,not pro2,I'm confused about it.Thanks for help — NitaX, Oct 20 '18 at 02:21
@Ele - https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/ — Jaromanda X, Oct 20 '18 at 02:21
the result I'm getting is 1,6,7,2,4,9,10,5,11,8,3 what result are you looking to get. Your set timeout doesnt have a time in miliseconds which means it defaults to 0 — Pari Baker, Oct 20 '18 at 02:28
so as expected your new promises are executing first as they are async and don't have to wait for setTimeout to execute. Every time you call a Promise and resolve it it executes before the console.log gets a chance to execute because it is not waiting for the setTimeout. — Pari Baker, Oct 20 '18 at 02:33
@Pari Baker I add parameter 1000 to all setTimeout ,but it also could be two result like before.I think after 4 it should be 5,but maybe as JaromandaX said,it can also be 1 6 7 2 4 5 9 10 8 3 11 — NitaX, Oct 20 '18 at 02:35
@NitaX I wouldn't think it should be five, if setTimeout has already executed, if you add 1000, to the setTimeout that has the 9 in it it will execute the 5 before the 9 — Pari Baker, Oct 20 '18 at 02:37
@Pari Baker I think above results are all right,I put the code(not add 1000) into Chrome for execution,the result is 1,6,7,2,4,5,9,10,11,8,3;Then,I add 1000 to all setTimeout,the result is also 1,6,7,2,4,5,9,10,11,8,3;so I think the result is not unique — NitaX, Oct 20 '18 at 02:52
right so as it stands the engine matters.... but correct or wrong depends on that. — Pari Baker, Oct 20 '18 at 03:00
@Ele - that nodejs document describes the nodejs **event loop**, timers and next tick — Jaromanda X, Oct 20 '18 at 03:23

traktor · Accepted Answer · 2018-10-20T04:01:41.353

Hi Nita and welcome to Stack Overflow.

The order of log appearance in a browser is determined from a requirement in the HTML5 standard to execute call backs for resolved (fulfilled) promises before executing any call backs for expired timers in the timer queue.

The ECMAScript specification itself makes no attempt to define the execution priority of promise jobs that execute call backs to then handlers after promise settlement, with respect to other asynchronous events in the host environment.

Answers to Promise.then Job execution order go into more detail and provide links to relevant standards.

So, for an HTML5 compliant browser, the order of logs will be

 1, 6, 7, 2, 4, 5, 9, 10, 11, 8, 3

because execution of then handler callbacks set up on a fulfilled promise take priority over timer call backs.

The HTML5 standard does not dictate the relative priorities of timer and promise callbacks in non-browser environments such as Node.js.

So discrepancies between the order of logs made to the console can be attributed to differences in the host environment.

The take home thought is setting up code to rely on the outcome of race conditions between timers and promise call backs is a somewhat brittle exercise - it relies on host environment implementation.

Why does the Javascript EventLoop have different result？

1 Answers1