CODEWITHSUNDEEP
javascriptnode.jsmultithreadingpromise
adrayv
adrayv

Reputation: 389

How does the JS event loop behave when a Promise's resolution depends on setTimeout?

console.log('1')
setTimeout(() => {
    console.log('2')
}, 0)
function three() {
    return new Promise(resolve => {
        setTimeout(() => {
            return new Promise(resolve => resolve('3'))
        },0)
    })  
}
three().then(result => console.log(result))
console.log('4')

This code snippet outputs 1 4 2

This is the behavior I would expect based on my understanding of javascript's event loop and concurrency model. But it leaves me with some lingering questions.

Before getting to those questions, I'll first break down my understanding of this code snippet.

Why code outputs 1

no explanation needed

Why code outputs 4

the callback that outputs 2 gets loaded into the event queue (aka macro task queue) after 0ms, but doesn't get executed until the main call stack is emptied.

even if three was a promise that was immediately resolved, its code is loaded into the job queue (aka microtask queue) and wouldn't be executed until the main call stack is emptied (regardless of the contents of the event queue)

Why code outputs 2

after console.log(4) the main call stack is empty and javascript looks for the next callback to load on the main stack. It's pretty safe to assume that at this point, some "worker thread" had already put the callback function that outputs 2 onto the macro task queue. This gets loaded onto the stack and 2 is output.

Why code does NOT output 3

This is where its a little blurry for me. The function three returns a promise that is then-ed in the main thread. Callback functions passed through then are loaded onto microtask queue and executed before the next task in the macrotask queue. So while you might think it'll run before the callback that logs 2, its actually theoretically impossible for it to run at all. That's because the Promise is only resolved via the callback function of its setTimeout, and that callback function (because of setTimeout) would only run if the main execution thread (the same thread that's waiting for the promise to resolve) is empty.

Why does this bother me

I'm trying to build a complete theoretical mental model of how javascript handles concurrency. One of the missing pieces in that model is the relationship between network requests, promises, and the event loop. Take the above code snippet, and suppose I replace three's setTimeout with some sort of network request (a very common thing in async web development). Assuming that the network request behaves similarly to setTimeout, in that when the "worker thread" is done, a callback is pushed to the macro task queue, it's hard for me to understand how that callback even gets executed. But this is something that happens literally all the time.

Can someone help me understand? Do I have any missing gaps in my current understanding of js concurrency? Have I made an incorrect assumption? Does any of this actually make any sense? lol

Upvotes: 0

Views: 732

Answers (2)

Slobodan Krasavčević
Slobodan Krasavčević

Reputation: 84

Why you assume that network request would behave as setTimeout? It is a Promise which resolved() would go in microtasks

Upvotes: 0

jfriend00
jfriend00

Reputation: 707328

Why code does NOT output 3

In this code:

function three() {
    return new Promise(resolve => {
        setTimeout(() => {
            return new Promise(resolve => resolve('3'))
        },0)
    })  
}
three().then(result => console.log(result))

You never resolve the first Promise that three() creates. Since that's the one that is returned form three(), then the .then() handler in three().then(...) is never called.

You do resolve the promise created inside the timer, but you're returning that promise only to the timer callback which does nothing.

If you change your code to this:

function three() {
    return new Promise(resolve => {
        setTimeout(() => {
            resolve('3');
        },0)
    })  
}
three().then(result => console.log(result))

Then, you would see the 3get output.

So, this doesn't have anything to do with the event loop or how it works. It has to do with not resolving the promise that three() returns so the .then() handler on that promise never gets called.

I'm trying to build a complete theoretical mental model of how javascript handles concurrency. One of the missing pieces in that model is the relationship between network requests, promises, and the event loop. Take the above code snippet, and suppose I replace three's setTimeout with some sort of network request (a very common thing in async web development). Assuming that the network request behaves similarly to setTimeout, in that when the "worker thread" is done, a callback is pushed to the macro task queue, it's hard for me to understand how that callback even gets executed. But this is something that happens literally all the time.

Network requests and promises and timers all go through the event loop. There are very complicated rules about how multiple events in queue at the same time are prioritized relative to one another. .then() handlers are generally prioritized first.

Think of the Javascript interpreter as this simplistic sequence.

 Get event from event queue
 If nothing in the event queue, sleep until something is in the event queue
 Run callback function associated with the event you pull from the event queue
 Run that callback function until it returns
     Note, it may not be completely done with its work because it may
     have started other asynchronous operations and set up its own
     callbacks or promises for those.  But, it has returned from the
     original callback that started it
 When that callback returns, go back to the first step above and get the next event

Remember that network requests, promises, timers and literally ALL asynchronous operations in node.js go through the event queue in this manner.

Upvotes: 2

Related Questions