1

community! I've been recently discovering how JavaScript works and came across interesting moment with order of elements being executed in Job Queue and Task Queue. As we all know, Job Queue has higher priority then Task Queue. But is it correct, that if async function like Promise.resolve depends on lower priority functions in Task Queue, than before completing the async function, we need to execute all functions from Task Queue ?

This can be seen on the example I've provided below:

setTimeout(()=>{
    console.log('1');
}, 0);
(https://i.stack.imgur.com/lb9Zr.png)

Promise.resolve('2').then(console.log);

console.log('3');

This code will have to come through the next steps:

  1. setTimeout is added to call stack
  2. setTimeout is pushed to WebAPI and popped from call stack
  3. Promise.resolve, after being recognized as async function returning promise, is pushed in Job Queue and in the same time setTimout callback is pushed in Task Queue
  4. console.log('3') is pushed on the call stack and executed and popped from call stack
  5. As call stack is empty, event loop pushes Promise.resolve on call stack and produces console.log function to be executed
  6. When the previous functions are popped, only then setTimeout callback will be pushed on call stack and executed

so in the console we have following output: 3 2 1 (https://i.stack.imgur.com/0eApX.png)

However, if we modify the code to be:

setTimeout(()=>{
    console.log('1');
}, 0);

Promise.resolve(setTimeout(()=>{
    console.log('2');        
}));

console.log('3');

We will have output: 3 1 2

(https://i.stack.imgur.com/bvPEp.png)

So, I suggest next steps:

  1. setTimeout is added to call stack
  2. setTimeout is pushed to WebAPI and popped from call stack
  3. Promise.resolve, after being recognized as async function returning promise, is pushed in Job Queue and in the same time setTimout callback is pushed in Task Queue
  4. console.log('3') is pushed on the call stack and executed and popped from call stack
  5. As call stack is empty, event loop pushes Promise.resolve on call stack, however this function depends on setTimeout which goes to WebAPI and then pushed in Task Queue. !!! And it is the most interesting part: elements in Task Queue executed using FIFO (first-in first-out) principle, so, as I suggest, event loop is forced to push first setTimout callback on call stack, which is blocking the one on which Promise.resolve is depending
  6. After first setTimeout callback is executed, popped -> setTimeout callback on which Promise.resolve depends now can be pushed, executed and popped.

To sum up, is it correct, that if async function like Promise.resolve depends on lower priority functions in Task Queue, than before completing the async function, we need to execute all functions from Task Queue ? P.S. I've attached screenshots of code + result using chrome console

  • "*Promise.resolve […] is pushed in Job Queue. [Later,] as call stack is empty, event loop pushes Promise.resolve on call stack*" - no. `Promise.resolve()` is called, executed, and synchronously returns a promise object. Then the `.then()` method is called on that promise, which again pushes it to, executes it on, and pops it from the call stack (returning another promise). It's this `.then()` call that does put the callback function (`console.log` here) in the job queue, and the job is only to run the callback function with the fulfillment value. The job does not involve `Promise.resolve`. – Bergi May 17 '23 at 13:49

1 Answers1

0
setTimeout(()=>{
    console.log('1');
}, 0);

Promise.resolve(setTimeout(()=>{
    console.log('2');        
}));

console.log('3');

This example is probably not what you intended - you are calling setTimeout synchronously here and creating a promise fulfilled to its timeoutId. It's the same as:

setTimeout(()=>{
    console.log('1');
}, 0);

let id = setTimeout(()=>{
    console.log('2');        
});
Promise.resolve(id);

console.log('3');

Without getting into spec/platform terminology too much: Promise resolution always comes before I/O and stuff like timers. Whenever platforms run handlers for I/O they will "run all microtasks" after each operation (so you can "starve the event loop" with microtasks - we even have a warning for process.nextTick in the docs in Node).

Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
  • Benjamin Gruenbaum, thanks for the answer. Have I understood you correctly that using the Promise.resolve and passing setTimeout to it, the Promise has been resolved and event loop takes callbacks from Task Queue, and the Promise doesn't depend on the setTimeout passed to it ? – SKorchisnkiy May 17 '23 at 13:42
  • 1
    @SKorchisnkiy `id` is a number. `Promise.resolve` creates a promise fulfilled with a number, which is then ignored by the code. There is no relation between the promise and the task queue in this example. – Bergi May 17 '23 at 13:45
  • @Bergi, many thanks for the answer. Now it's clear to me! – SKorchisnkiy May 17 '23 at 13:53