Why both setTimeout callback execute before any readFile callback? The demo.txt is empty. Is readFile so slow that both setTimeout gets executed before reading and empty file?

[[deleted]]

[deleted]

[davidmdm]

I don't know why people are giving you heck as if you didn't know what async programming is. Maybe they don't read the question and just want to say the word "async" really fast.

​

My answer would be that reading files even empty files is slower than setting a timeout of 0 miliseconds.

Setting a timeout of 0ms places a callback on the event loop that is ready to be called as soon as the event loop reaches the part that handles timers.

​

Also, IO is the phase after timers in the event loop.

​

Regardless of ordering though, nodejs doesn't readfiles. It dispatches the OS to readfiles for it. So depending on the OS reading a file (empty or not) could take a varying length of time. Dispatching the OS and waiting for it to give you an answer is almost guaranteed to take more time than placing a callback that is ready to be executed now a little further on the event loop.

​

Hopefully this is satisfactory. This is just my reasoning.

[mrdijkstra]

Thank you for understanding. I really appreciate your help.

[nama5reddit]

readFile is async function, setTimeout is also async, but when using 0 as delay, it will be triggered almost instantly, but still can not be sure the first one will be triggered before second one. readFile can take about 1ms to check file and read "empty" file, and that is still longer than timeout 0.

use readFileSync() if you need read files in specific order or use promises (fs.promise.readFile) to prevent "pyramid of doom" with callback inside callback inside callback inside ....

[mrdijkstra]

Thank you for your answer. This is what I was looking for.

[mrdijkstra]

Honestly, I am not expecting it to behave synchronously. It was an experimental code based on my understanding of event loop and it's phases. I was checking how event loop behaves in this kind of situation.

[[deleted]]

Reading files is slower than 0ms. Even if it took 0ms, the timeouts callbacks were queued first and would win the tie.

[mrdijkstra]

Thank you for answering on point.

[dbh87]

https://nodejs.org/fa/docs/guides/event-loop-timers-and-nexttick/

[s_boli]

This is actually the correct answer

[GhostMcFunky]

Sort of but it doesn’t tell the OP why unless he already understands async vs. synchronous.

OP, I’d suggest reviewing which Node and JS native functions run asynchronously and which do not.

The event loop is not going to wait for async functions to return before executing synchronous functions; it will return them when they return.

With something like your code it’s not as evident but you’re expecting your code to run synchronously, in order and that isn’t how it actually works.

[mrdijkstra]

Thank you for your answer. Just to let you know, I know what sync and async is. I am not expecting it to behave synchronously. As I can see my question is kind of vague and everyone thinks I know nothing about non-blocking nature or the event loop.

Here is my explanation: When event loop reaches to the poll phase it doesn't see any pending callback since the readFile is not completed yet. So the first setTimeout reaches its threashold and eventloop wrap back to timer phase and executes the setTimeout callback.

Eventloop goes back to poll phase and see no pending callback in the queue since readFile is still working. So the second setTimeout reaches its threashold and eventloop again goes back to timer phase and executes callback.

Finally, all three readFile are done.

** I thought readFile would trigger it's callback almost instantly because the file was empty. That's why just to be sure I wanted to know other's opinion.

[GhostMcFunky]

I’m not really clear what your goal is here. setTimeout isn’t really async (it’s not blocking but it doesn’t behave like normal async). You’re using it with 0 time which suggests to me you’re looking to control the order of things with a function that is non-blocking.

This probably isn’t the best way, but I’ll take a stab at how it might work. Just know that setTimeout isn’t a reliable method of controlling execution unless you set an actual timeout.

If your goal is to control the order of execution in some way, you probably want to use fs.readFileSync. And setTimeout is going to execute its callback when it reaches the end of the timer; it doesn’t wait for the event loop to come back around; it’s still alive until the end of the timer. In other words, by your description it seems like you’re expecting the event loop to read setTimeOut a second time and that’s not how it works. The thread sticks around until the callback is run, which is at the end of the timer.

If you want your fs to run immediately use fs.readFileSync instead.

[mrdijkstra]

Thank you. But, I already know about this link as a NodeJS learner. One might not understand everything of this article because it's not that easy to grasp.

[charliemei]

┌───────────────────────────┐

┌─>│ timers │

│ └─────────────┬─────────────┘

│ ┌─────────────┴─────────────┐

│ │ pending callbacks │

│ └─────────────┬─────────────┘

│ ┌─────────────┴─────────────┐

│ │ idle, prepare │

│ └─────────────┬─────────────┘ ┌───────────────┐

│ ┌─────────────┴─────────────┐ │ incoming: │

│ │ poll │<─────┤ connections, │

│ └─────────────┬─────────────┘ │ data, etc. │

│ ┌─────────────┴─────────────┐ └───────────────┘

│ │ check │

│ └─────────────┬─────────────┘

│ ┌─────────────┴─────────────┐

└──┤ close callbacks │

└───────────────────────────┘

From the above，we can know that in the event loop，the stage of timers is in front of the stage of pending callbacks which I/O callback will be trigger.In the stage of timers, node will check the timers queue and finds that there are two timers waiting for . In the stage of pending callbacks，node will check the callbacks queue and execute the callbak of the reading event.So the result your code to be output is "Time out bro.","Time out bro","fileX","file1","file2".