I've been reading some NodeJs articles in order to understand its async nature during which I found this and really liked it Node.js, Doctor’s Offices and Fast Food Restaurants – Understanding Event-driven Programming
There is a thing called EventLoop
that is FIFO based queue. They say when an async function gets hit, it gets put to EventLoop and will continue to get executed over there.
I am little confused here. For example it is said here:
In actuality, async functions like setTimeout and setInterval are pushed onto an queue known as the Event Loop.
and in the same article:
The Event Loop is a queue of callback functions. When an async function executes, the callback function is pushed into the queue. The JavaScript engine doesn't start processing the event loop until the code after an async function has executed.
But it is different than this image:
Let's look at the following example:
console.log("Hello,");
setTimeout(function(){console.log("World");},0);
So from what I understand from those different explanations,
function(){console.log("World");}
part of the setTimeout()
function, that is the callback, will be put in EventLoop. Once the setTimeout
is done, it will execute the EventLoop
as well.setTimeout(function(){console.log("World");},0);
will be put the EventLoop and will get executed...I am confused even more now. It should be something simple but I guess a good but simple explanation would be nice for me for the following questions:
Just think of Node's event loop as the "main function" that loops on the client side (except Node is on the server side, and you don't technically need an event loop in your code, since it's event based :).
Think about each client that connects as a JS object that runs through your code again, in it's own address space, with it's own variables, but in the same exact process, and same exact CPU as the rest of your program (you can cluster this, but generally that's how it works out of the box).
Worker threads are what blocking I/O get segmented off into, and with plugins, you can even spread worker threads into different Node servers (File I/O, DB I/O, Network access, etc, all get put into worker threads).
While the event you make gets put in a queue, when it's executed, it runs in the main event loop (kind of), but more importantly, the event itself is placed in the event loop (the trigger that will call it).
This is all part of the V8 engine (the event loop, that is). What makes Node so great is it lets hundreds of thousands of clients into the same loop, and isolates blocking I/O.
The main take away point of this is that: Node is always doing something if something needs to be done, always.
Where as with other frameworks, I/O blocks the execution of the rest of the code.
Basically, almost anything you normally write will happen in the event loop, but not exactly. What's meant to happen is your code runs once, then it just plugs in events, and quits.
Does that make sense?
So, while your code is done running, any events you queued up, (including more of your code, for example) still resides in the event loop.
Node is very different from everything else, but that's a pretty good explanation to get you started.
I wrote a lot more details on Quora if you're interested... https://www.quora.com/How-good-is-Node-js