Will async/await block a thread node.js

Solution 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.

Solution 2:

async/await provide an alternative way for what you would traditionally do with then calls on a promise. Nor Promises, nor async nor await create new threads.

When await is executed, the expression that follows it is evaluated synchronously. That expression should evaluate to a promise, but if it is not, it is wrapped into one, as if you had await Promise.resolve(expression).

Once that expression is evaluated, the async function returns -- it returns a promise. Then code execution continues with whatever code follows that function call (same thread) until the call stack is empty.

At some point the promise -- that was evaluated for the await -- will resolve. This will put a microtask in a microtask queue. When the JavaScript engine has nothing more to do in the current task, it will consume the next event in the microtask queue (FIFO). As this microtask involves a resolved promise, it will restore the previous execution state of the async function and continue with whatever comes next after the await.

The function may execute other await statements, with similar behaviour, although the function now no longer returns to where it was originally called from (as that call was already processed with the first await), it merely returns leaving the call stack empty, and leaves the JavaScript engine to process the microtask and task queues.

All this happens with the same thread.