I can’t figure out how the code below works, my example of work contradicts the execution of the event loop.
async function main() {
for (let i = 0; i < 10; i++) {
await new Promise(res => setTimeout(res, 1000));
console.log("time + i");
}
}
main();
My example of how this code works:
function main added to Call stack.
call the loop for.
call function Promise which return setTimeout.
setTimeout added to Macrotask.
function main add to Microtask (await resolve Promise).
Some remarks about the steps you listed:
call function Promise which return setTimeout.
Promise is called as a function, but more specifically as a constructor
It doesn't return setTimeout, but ... a promise.
setTimeout added to Macrotask.
setTimeout is not added to a queue. setTimeout is executed, with res and a delay as argument. It returns immediately. The host has registered the callback and timeout using non-JavaScript technology. There is nothing about this in the queues yet.
function main add to Microtask
More precisely, the current execution context of main is saved. Once the awaited promise has resolved, only then will a job be put in the microtask queue with the purpose to resume the suspended execution of main.
Detailed steps
Here are the steps 3, 4 and 5 in more detail:
The Promise constructor is called, which immediately calls the callback given as argument.
setTimeout is called, which registers its callback argument res for later execution.
The setTimeout call immediately returns. Its return value is a unique timer ID, but that value is ignored by the Promise constructor
The Promise constructor returns a promise that is in a pending state.
The await saves the current execution context of main, and makes the main function return with a pending promise.
This is the end of this synchronous execution cycle, and JavaScript now monitors the job queues.
In a following step we have this:
The setTimeout implementation (non-JavaScript) sees that the 1000 delay has passed and places a job in a (macrotask) job queue.
The JavaScript engine gets the job from that queue, and executes it. In this case it means it executes res (starting from an empty call stack).
The call of res will fulfill the promise that was created with new Promise. This creates a job in a (microtaks) job queue to restore the execution context of main.
res returns and the callstack is empty again.
And then, as part of the same "task":
JavaScript reads the microtask queue and executes that job: the main execution context is restored (put on the callstack), with variable i equal to 0 and execution continuing with console.log
The loop makes its second iteration, and the operand of await is evaluated again, calling again the Promise constructor (see the steps at the top). The difference here is that when await makes main return (again) it is returning from a "resume" call that was made from a job, not from JavaScript code. This will be the case for all next executions of await.
And so it continues for all iterations of the (asynchronous) loop. When the loop has completed:
The resumed main function ends with an implicit return undefined. This resolves the promise that main had returned when it had executed await for the first time -- when it returned to the top-level script where main(); had been called.
As there is no code that is awaiting that promise to be resolved, nothing more happens.
Related
This question already has answers here:
Correct way to write a non-blocking function in Node.js
(2 answers)
Closed 8 months ago.
function main() {
console.log("S-1");
setTimeout(() => {
console.log("setTimeout");
}, 0);
new Promise((resolve, reject) => {
for (let i = 0; i < 10000000000; i++) {}
resolve("Promise");
}).then((res) => console.log(res));
console.log("S-2");
}
// Invoke function
main();
When I run the main() function, the output I get is:
'S-1'
'S-2'
'Promise'
'setTimeout'
After 'S-1' is logged, there is a big time gap, and then after few seconds, the rest gets logged, at once.
Shouldn't the time gap occur after logging 'S-2'?
The function inside the Promise constructor runs synchronously, on the same (and only) main thread as the rest of the script. Constructing a Promise doesn't result in a separate thread being created.
If you do some heavy processing immediately inside a Promise constructor, that heavy processing will have to complete before control flow is yielded back to the outside of the Promise constructor. In this case, it means that the many iterations of the loop must finish before:
the constructor finishes completely
The constructor resolves to a Promise
That Promise gets a .then handler attached to it
Finally, the console.log("S-2"); line runs
To get the output you're desiring or expecting without moving the logs around, you'd have to offload the expensive code to a different environment, such as to a worker or a server (using a network request).
As #CertainPerformance had said, Javascript can only handle one call-stack. It needs to finish this thread once and for all. For promises and timeouts, it uses the job and task queues. The event loop prioritizes the job queue and then the task queue.
Lets try to understand what you wrote in terms of call-stack and queues.
function main() {
// 1. execute straight forward
console.log("S-1");
// 2. sets / schedules a timer, the anonymous function is then stored in the callback
setTimeout(() => {
console.log("setTimeout");
}, 0);
// 3. create a new Promise, with the constructor acting as executor
// executes immediately, as its designed to set the state of the Promise for the then() to react to.
new Promise((resolve, reject) => {
for (let i = 0; i < 10000000000; i++) {}
// 3.5 the resolve signals that the execution is finished
// either returns the promise or passes through the then()
resolve("Promise");
// 4. after the promise execution has been resolved,
// then() creates another anonymous function, and stores in the callback.
// at this point there are 2 entries in the callback
}).then((res) => console.log(res));
// 5. once the above Promise executor has been executed, execute this
console.log("S-2");
// By now, since both the timer and promise execution has been done,
// the timeout is put into the Task Queue and the Promise then() is put into the Job Queue.
}
// 0. puts this into the call stack and execute
main();
// 6. The event loop deques all of the call stack from the job queue and puts it into the main call stack to execute.
// hence, the then() is executed first
// 7. The event loop then deques all of the call stack from the task queue and puts it into the main call stack to execute.
// hence, the timeout function is executed next.
If you want to make it a callback.
function main() {
console.log("S-1");
setTimeout(() => {
console.log("setTimeout");
}, 0);
new Promise((resolve, reject) => {
setTimeout(() => {
resolve("promise");
}, 1000);
}).then((res) => console.log(res));
console.log("S-2");
}
// Invoke function
main();
Reference: https://medium.com/#idineshgarg/let-us-consider-an-example-a58bb1c11f55
in this diagram is says that the event Loop will run the I/O callbacks (the axios request), then the check phase (setImmediate), but when i tested this, it was the opposite, i need explanation of the execution of that code.
console.log('first'); // logs instantly
setImmediate(() => console.log('immediate')); // will be executed in the next iteration of the event loop.
new Promise((resolve) => { // starts in promise in pending state
console.log('insidePromise');
const data = 'Promise';
resolve(data);
}).then((d) => console.log(d)); // prints after Promise is resolved
Output -
first
insidePromise
Promise
immediate
When the Promise is called it starts in a pending state and waiting for resolve.
setImmediate - triggers here before resolve is processed as setImmediate will have to be executed in the event loop.
https://nodejs.dev/learn/understanding-javascript-promises
Once a promise has been called, it will start in a pending state. This means that the calling function continues executing, while the promise is pending until it resolves, giving the calling function whatever data was being requested.
https://nodejs.dev/learn/understanding-setimmediate
Any function passed as the setImmediate() argument is a callback that's executed in the next iteration of the event loop.
If i declare a function like below:
function a(){
//do something
}
And if i execute it with a() it gets putted onto the top of the callstack and gets popped of when its finished. While the function is in the callstack the main thread is blocked and cant do other things until the callstack is empty.
But what happens exactly with an async function?
if i do:
async function b() {
//do something
}
The function returns an promise and does not block the main thread. Does this mean this function gets passed to the web API instead of the callstack? and then after its done it gets passed to the callback que and then gets passed to the callstack and so that we can execute the callback function?
b.then(function() {
//do something after finish
})
Yes, async functions will be on the call stack during their execution just like normal functions. You can consider the desugaring of the await keyword:
function log(x) {
console.log("at "+x);
}
function delay(t) {
return new Promise(resolve => setTimeout(resolve, t));
}
async function example() {
log(1);
await delay(50);
log(2);
return 3;
}
function example2() {
log(1);
return delay(50).then(function cont() {
log(2);
return 3;
})
}
An example() call works exactly like an example2() call. The called function gets pushed on the stack, calls log(1) which gets pushed on the stack and runs, when that returns (gets popped from the stack) it calls delay(50) which gets put on the stack and runs, and so on. Now, when the await operator is evaluated, the async function will take the operand promise, attach callbacks using a .then() call, and then return from the example() call a promise for the eventual completion of the function body. So when it reaches the await keyword, it gets popped from the stack, and the caller may continue running synchronous code (that will typically involve doing something with the returned promise).
Then, when the promise is resolved (in the above example, when the timeout is hit), jobs are scheduled to run the attached then callbacks. They might have to wait for the event loop to become idle (the callstack to become empty), and then when the promise job starts the code is put on the callstack again. In example2, this is the cont function that will get called, in the async function it will be continuation of the example body, where it left off at the await. In both cases, it calls log(2) which gets pushed on the stack and runs, and when that returns (gets popped from the stack) the return 3 statement is executed which resolves the promise and pops the execution context from the stack, leaving it empty.
it does go onto the call stack, when its time for the async function to run it gets moved off of the call stack until the function is either fulfilled.or rejected. at this point it get moved into the callback queue while all other synchronous functions can continue to execute off of the callstack, then when the callstack is empty, the event loop looks in the callback queue for anything else that needs to be executed. if there is anything in the callback queue the event loop pushes the callback into the call stack to execute.
I have two functions, one function, asyncTest_returnPromise simply returns a promise, and another function, asyncTest, calls that promise 3 times by calling Promise.all(promises) on an array of promises. Within each promise in the array, I send one value ("Foo") to the console before the asyncTest_returnPromise function is called, and send another value ("Bar") to the console after it is called.
Given my understanding of the Promise.all function, I would have expected each promise within the array to be processed only after the subsequent promise had been fulfilled, meaning that as both console.log statements are within each promise in the array, the result would have been:
Foo
Bar
Foo
Bar
Foo
Bar
Instead, however, the output seems to be:
Foo
Foo
Foo
Bar
Bar
Bar
As all instances of "Foo" have been sent to the console before even the first "Bar", it seems to me these promises must be being processed concurrently.
Here are the two functions:
function asyncTest_returnPromise() {
return new Promise((resolve, reject) => {
resolve()
})
}
function asyncTest() {
var promises = []
for (i = 0; i < 3; i++) {
promises.push(new Promise((resolve, reject) => {
console.log("Foo")
asyncTest_returnPromise().then(_ => {
console.log("Bar")
resolve();
})
}))
}
Promise.all(promises)
}
asyncTest();
So I would like to know, have I misunderstood the purpose of Promise.all or how it works? Has some other part of my code caused all "foo" outputs before all the "bar" outputs? Is there something I need to do to have the entirety of each promise complete before moving on to the next one?
They are running asynchronously.
Each time around the loop you:
Log Foo
Create a promise (which resolves immediately)
Use then to queue up a function to run after the promise resolves
Then the loop goes around for the next iteration.
Afterwards, when the asyncTest function is finished , the event loop is free to look at the queued up functions.
Since all the promises are resolved, they each run (and log Bar).
If you want to wait for a promise before going around the loop again, then you should look at the await keyword which would let asyncTest pause (and go to sleep) until a promise resolved.
It's just how Event Loop works. Let me explain how it's processed in simple words:
First, the loop starts and runs 3 times. Each time it creates a new microtask and puts it in the microtask queue for later handling. The order in which those microtasks have been created is kept.
Now those microtasks are being handled one at a time, synchronously. Each of those microtasks (which are run synchronously as the Loop runs) executes console.log('Foo'); and then creates another microtask (another Promise) which are queued by the .then() call. So this additional microtask is put into the queue (behind those three first microtasks). It happens for every microtask created by the loop (so it's 3 times). This is where you have Foo printed 3 times.
Now that all our microtasks (3) have been processed, the Event Loop keeps going and takes the next microtasks for processing. This time it's a microtask that runs console.log('Bar');. It happens also three times. Here's where you get Bar printed 3 times.
Of course, there's more that happens in the Event Loop but this is essentially what happens with your Promises here.
Why is there no async stacktrace when rethrowing an asynchronous exception? With node 12+, the exception when running the following code:
async function crash() {
try {
await (async () => {throw new Error('dead');})();
} catch (e) {
throw new Error('rethrow');
}
}
async function foo() {
await new Promise(resolve => setTimeout(() => resolve(), 1));
await crash();
}
async function entrypoint() {
try {
await foo();
} catch(e) {
console.log(e.stack);
}
}
entrypoint();
is woefully incomplete:
Error: rethrow
at crash (/async-stackt/crash.js:6:15)
I found a workaround by defining the exception in the beginning of crash(), which yields a much nicer:
Error: rethrow
at crash (/workaround.js:2:17)
at foo (/workaround.js:12:11)
at async entrypoint (/workaround.js:17:9)
This is not optimal, since the error has to be constructed in advance whether it is needed or not, and the stacktrace is somewhat imprecise.
Why is the stack trace incomplete when throwing an error from an async catch block? Is there any workaround or change to the code to get a complete stack trace in the first place?
That stack trace is showing you what's ON the stack at that time. When you make an asynchronous call such as setTimeout(), it runs the setTimeout() which registers a timer that will fire some time in the future and then it continues execution. Since you're using await here, it pauses the execution of foo(), but it continues execution of the code after where foo() was called. Since that's also an await, it continues executing the code that called entrypoint(). After that finishes, the stack is entirely empty.
Then, sometime later, your timer fires and its callback gets called with a completely clean stack. In your case, the setTimeout() callback just calls resolve() which then triggers a promise to schedule its resolve handlers to run on the next event loop tick. That returns back to the system and the stack frame is again empty. On that next tick of the event loop, the promise resolve handlers are called and that satisfies the await on that promise which is inside a function context. When that await is satisfied, the rest of that function starts to execute.
When that function gets to the end of its execution, the interpreter knows that this was a suspended function context. There is no return from the function to happen because that already happened earlier. Instead, since this is an async function, the end of the function execution resolves the promise that this async function returns. Resolving that promise then schedules its resolve handlers to be called on the next tick of the event loop and then it returns control back to the system. The stack frame is again empty. On that next tick of the event loop, it calls the resolve handlers which satisifies the await in the await foo() statement and the entrypoint() function can continue to run, picking up where it was last suspended.
So, the key here is that when the timer goes off, execution goes from foo back to entrypoint, not via a stack and a return statement (that function already returned awhile ago), but via promises getting resolved. So, at the time the timer goes off and you then call crash(), the stack is indeed empty except for the function call to crash() itself.
This concept of an empty stack when promises are resolved goes to the heart of how an async function actually works so it's important to understand that. You have to remember that it pauses the internal execution of the function containing the await, but as soon as it hits the first await, it immediately causes the function to return a promise and the the callers continue further execution. The caller is not paused unless they also so an await in which case the callers of the caller continuing executing. At some point, somebody gets to continue executing and eventually, it returns control back to the system with a now-empty stack.
The timer event (or some other promise triggering event) then gets called with a completely empty stack frame with no remnants from the original call sequence.
Unfortunately, the only work-around I'm aware of now is to do what you found - create the Error object earlier when the original stack is still alive. If I remember correctly, there is a discussion about adding some features to the Javascript language to make asynchronous tracing easier. I don't remember the details of the proposal, but perhaps by remembering what the stack frame was when the function was originally called since what it is after the promise is resolved/rejected and when the Error object is created is no longer very useful.
In case anyone was unfamiliar with how async functions work and how they suspend their own execution upon the first await, but then return early, here's a little demo:
function delay(t) {
return new Promise(resolve => {
setTimeout(resolve, t);
});
}
async function stepA() {
console.log("5");
await stepB();
console.log("6");
}
async function stepB() {
console.log("3");
await delay(50);
console.log("4");
}
console.log("1");
stepA();
console.log("2");
This generates the following output. If you follow this execution path step-by-step, you will see how each await causes an early return from that function and can then see how the stack frame will be empty once the promise that is being awaited gets resolved. This is the output generated:
1
5
3
2
4
6
It's clear why 1 is first as it's the first thing to execute.
Then, it should be clear why 5 comes next when stepA() is first called.
Then, stepA calls stepB() so as it begins to execute, that's why we see 3 next.
Then, stepB calls await delay(50). That executes delay(50) which starts a timer and then immediately returns a promise that is hooked to that timer. It then hits the await and it stops execution of stepB.
When stepB hit that await, it causes stepB at that point to return a promise that comes from the function being async. That promise will be hooked to stepB execution eventually (in the future) getting a chance to finish all of its execution. For now the execution of stepB is suspended.
When stepB returns its promise, that goes back to where stepA executed await stepB();. Now that stepB() has returned (an unfulfilled promise), then stepA hits its await on that unfulfilled promise. That suspends the execution of stepA and it returns a promise at that point.
So, now that the original function call to stepA() has returned (an unfulfilled promise) and there is no await on that function call, that top level code after that function call continues to execute and we see the console output the 2.
That console.log("2") is that last statement to execute here so control is returned back to the interpreter. At this point, the stack frame is completely empty.
Then, sometime later, the timer fires. That inserts an event in the JS event queue. When the JS interpreter is free, it picks up that event and calls the timer callback associated with that event. This does only one thing (call resolve() on a promise) and then returns. Calling resolve on that promise schedules that promise to trigger it's .then() handlers on the next tick of the event loop. When that happens, the await on the line of code await delay(50); gets satisfied and execution of that function resumes. We then see the 4 in the console as the last line of stepB executes.
After the console.log("4"); executes, stepB has now finished executing and it can resolve it's async promise (the one returned by it earlier). Resolving that promise tells it to schedule its .then() handlers for the next tick of the event loop. Control goes back to the JS interpreter.
On the next tick of the event loop, the .then() handlers notify the await in the await stepB(); that the promise has now been resolved and execution of stepA continues and now we see 6 in the console. That is the last line of stepA to execute to it can resolve its async promise and return control back to the system.
As it turns out, there is nobody listening to the async promise that the call to stepA() returned so there is no further execution.
I ran into the same issue in Node 12 and found out that it was fixed in a later version of V8: commit.
Gotta wait for Node 14, I guess...
The bug had to do with the stack trace not being tracked in catch blocks. So one workaround is to use the Promise's .catch function instead:
async function crash() {
await (async () => {throw new Error('dead');})()
.catch(e => { throw new Error('rethrow'); });
}