javascript - Will async/await block a thread node.js

Question

When async/await used in a node.js function, will it block the node.js thread untill it executes the next line of code ?

Answer 1

async/await does not block the whole interpreter. node.js still runs all Javascript as single threaded and even though some code is waiting on an async/await, other events can still run their event handlers (so node.js is not blocked). The event queue is still being serviced for other events. In fact, it will be an event that resolves a promise that will allow the await to stop awaiting and run the following code.

Code like this:

await foo();            // foo is an async function that returns a promise
console.log("hello");

is analogous to this:

foo().then(() => {
    console.log("hello");
});

So, await just puts the following code in that scope into an invisible .then() handler and everything else works pretty much the same as if it was actually written with a .then() handler.

So, await allows you to save the writing of the .then() handler and gives the code a synchronous look to it (though it isn't really synchronous). In the end it's a shorthand that lets you write async code with fewer lines of code. One does need to remember though that any promise that can reject must have a try/catch somewhere around it to catch and handle that rejection.

Logically, you can think of what node.js does when it encounters an await keyword when executing a function as the following:

1. Function call is made
2. The interpreter sees that the function is declared as async which means that it will always return a promise.
3. The interpreter starts executing the function.
4. When it encounters an await keyword, it suspends further execution of that function until the promise that is being awaited resolved.
5. The function then returns an unresolved promise.
6. At this point, the interpreter continues executing whatever comes after the function call (usually a fn().then() is followed by other lines of code). The .then() handlers are not executed yet because the promise is not yet resolved.
7. At some point this sequence of Javascript finishes and returns control back to the interpreter.
8. The interpreter is now free to serve other events from the event queue. The original function call that ran into an await keyword is still suspended, but other events can be processed now.
9. At some future point, the original promise that was being awaited gets resolved. When it's time for that to get processed in the event queue, the previously suspended function continues executing on the line after the await. If there are any more await statements, then the function execution is again suspended until that promise resolves.
10. Eventually the function hits a return statement or reaches the end of the function body. If there is a return xxx statement, then the xxx is evaluated and its result becomes the resolved value of the promise that this async function has already returned. The function is now done executing and the promise it previously returned has been resolved.
11. This will cause any .then() handlers attached to the promise that this function previously returned to get called.
12. After those .then() handlers run, the job of this async function is finally done.

So, while the whole interpreter doesn't block (other Javascript events can still be serviced), the execution of the specific async function that contains the await statement was suspended until the promise that was being awaited resolved. What's important to understand is step 5 above. When the first await is hit, the function immediately returns an unresolved promise and code after this function is executed (before the promise being awaited is resolved). It's for this reason that the whole interpreter is not blocked. Execution continues. Only the insides of one function are suspended until a promise is resolved.