1

I want to start by saying that I understand quite well async in JavaScript by using promises (async/await) and callbacks.

The way I see it regarding Promises in Nodejs is that if you start using a Promise you have to keep using that flow until the end of the app, either by using Promise Chaining or Promise.all() etc. methods.

Let's take into consideration the following simple app:

require('http').createServer().on("request", 

    async (req, res) => {

        // MY PROMISE
        myPromise("error").then( event => console.log(event)).catch( error => console.log(error) );

        // RUNS BEFORE THE PROMISE
        console.log("1");

        // RESPONSE SENDING
        res.end("OK");
    } 
)
.listen(3000);

This is a simple example, but let's say that in the Promise we have to retrieve some info from the DB or anything else that takes a long time.

In case I don't use AWAIT to block the loop until the promise is either resolved or rejected, the code will run on to the next line etc. Only later on the console.log from the Promise will show up.

So by using AWAIT I block the event loop and by not using it I dont get the info from the Promise.

Then why should I not use a sync code in the first place?

Is there another way to use Promises in an app?

Thank you!

SillyStack
  • 29
  • 5
  • Worth reading [Does async/await block the event loop?](https://stackoverflow.com/questions/51583483/does-async-await-blocks-event-loop) – jarmod Jul 18 '22 at 20:38
  • 1
    I think @jarmod answered your question @SillyStack. `await` doesn't block nodejs the event loop. Usually, methods that block the event loop warn you in the description, for example: `fs.readFileSync` or `crypto.pbkdf2Sync` – Alexander Yammine Jul 18 '22 at 20:42
  • Hi @AlexanderYammine. Thank you for your quick reply! I have done several tests and ALWAYS ```await``` blocked the event loop. In the above example, or calling the resolve / reject functions with setTimeout, setImmediate etc. I know there is a big debate over ```AWAIT```, I am just saying what I know from my tests. – SillyStack Jul 18 '22 at 20:51
  • I think you have not understood what the linked answer is saying. The tests that you ran don't show what you think they show. – jarmod Jul 18 '22 at 20:54
  • Try this [MSDN article on await](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#description). Note that when they use the word 'paused', they do not mean that the event loop is blocked. – jarmod Jul 18 '22 at 20:59
  • Sorry @jarmod, I have not spotted your answer! I have looked over the link you provided, and as I mentioned I was not expecting ```await``` to block the event loop, since it is just syntactic sugar. But, I can confirm you that in the above **simple case**, it halts the loop until the promise is resolved and only then it goes on. Am I doing something wrong? – SillyStack Jul 18 '22 at 21:12
  • @jarmod, thanks for the MSDN Link. I think I get it know what happens. According to a paragraph from there (_An await splits execution flow, allowing the caller of the async function to resume execution. After the await defers the continuation of the async function, execution of subsequent statements ensues._). So it pauses the execution of the statments **IN THE PRESENT REQUEST**. The other requests are not blocked since the event loop continues go run. Right? – SillyStack Jul 18 '22 at 21:19
  • It pauses the execution of the async function, yes. So the `console.log()` that you presumably have immediately *after* calling `await somefunc()` will not execute until that promise is settled. Other events continue to happen and can be processed in the meantime. – jarmod Jul 18 '22 at 21:24
  • 1
    @jarmod the fact that MY REQUEST was paused for the time it took the promise to resolve, made me think FALSELY that the whole event loop was blocked for that period of time. Anyway, from what I understood so far, Nodejs should be used mainly for I/O tasks and avoid CPU intensive work, even in Promises etc. Thank you very much again, you opened my eyes! – SillyStack Jul 18 '22 at 21:35

1 Answers1

2

Thanks to @jarmod comments and the provided MSDN article on await, I think that a flexible solution is to use AWAIT, even more so for those having a deep rooted sync code background.

From that article this paragraph made me understand what really happens:

An await splits execution flow, allowing the caller of the async function to resume execution. After the await defers the continuation of the async function, execution of subsequent statements ensues.

Prior, it seemed to me that THE WHOLE event loop was blocked until the Promise was resolved. Yet, in fact, ONLY MY REQUEST was paused for that amount of time. The App processed other requests meanwhile.

Of course, all the requests, in turn, would experience the same "pause" until the fulfillment of the promise.

jarmod
  • 71,565
  • 16
  • 115
  • 122
SillyStack
  • 29
  • 5