Understanding Node Event Loop

Home / Understanding Node Event Loop

Understanding Node Event Loop

December 9, 2015 | Article | No Comments

Event I/O programming using node js is simple. Node has pulled speed and scalability on the fingertips of the common programmers.

But the event loop approach comes with a price, even though you are not aware of it. Here we will discuss about how node works, technically the node event loop and what we do’s and don’ts on top of it.

Event-Queue Processing Loop

Concurrent is true nature of Node and it is achieved by event loop.

Event loop can be thought as a loop that processes an event queue. Interesting events happen and go in a queue, waiting for their turn. Then, there is an event loop popping out these events, one by one, and invoking the associated callback functions, one at a time. The event loop pops one event out of the queue and invokes the associated callback. When the callback returns the event loop pops the next event and invokes the associated callback function. When the event queue is empty, the event loop waits for new events if there are some pending calls or servers listening, or just quits of there are none.

For example, we will create a new file as hello.js and write these:

setTimeout(function() {
    console.log('World!');
}, 2000);
console.log('Hello');

run it using the node command line tool.

node hello.js

You should see the word “Hello” written out first and then the word “World!” will come out 2 seconds later. If we see the code, the word “World!” appears first but it is not the case when we execute the code. Remember that Node is using event loop. When we declare anonymous function that print out “World!”, this function is not executed yet. The function is passed in as the first argument to a setTimeout() call, which schedules this function to run in 2000 miliseconds (2 seconds) later. Then, next statement is executed which will prints out “Hello”. Two seconds later, the setTimeout is execute as the timeout event is occurred. This means the word “World!” is printed out.

So, the first argument to the setTimeout call is a function we call as a “callback”. It’s a function which will be called later, when the event we set out to listen to occurs.

After our callback is invoked, Node understands that there is nothing more to do and exits.

Callbacks that Generate Events

In above example, we only use one-time execution. We can keep Node busy and keep on scheduling callbacks by using this patterns:

(function schedule() {
  setTimeout(function() {
    console.log('HelloWorld!');
    schedule();
  }, 10000);
})();

If you look it, it is similar to recursive function, but it is not.

We trap the whole thing inside a function named “schedule” and invoking it immediately after declaration. This function will schedule a callback to execute in 1 seconds. This callback, when invoked, will print “Hello World!” and then run schedule again.

On every callback, we registering a new one to be invoked one second later, never letting Node finish.

Not Blocking

The primary concern and main use case for an event loop is to create highly scalable servers. Since an event loop runs in a single thread, it only processes the next event when the callback finishes. If you could see the call stack of a busy Node application you would see it going up and down really fast, invoking callbacks and piling up the next event in line. But for this to work well you have to clear the event loop as fast as you can.

There are two main categories of things that can block the event loop: synchronous I/O and big loops.

Node API is not all asynchronous. Some parts of it are synchronous like, for instance, some file operations. Don’t worry, they are very well marked: they always terminate in “Sync” – like fs.readFileSync – , and they should not be used, or used only when initializing. On a working server you should never use a blocking I/O function inside a callback, since you’re blocking the event loop and preventing other callbacks – probably belonging to other client connections – from being served.

The second category of blocking scenario is when a giant loop is performed. A giant loop in this term is a loop which take a lot of time like iterating over thousands of objects or doing complex time-taking operations in memory.

Let see an example:

var open = false;

setTimeout(function() {
    open = true;
}, 1000);

while(!open) {
    // wait
}

console.log('opened!');

You would expect the code to work, seeing the setTimeout() will surely be executed on next 1 second. However, this never happens as the node will never execute the timeout callback because the vent loop is stuck on the while loop, never giving the timeout event.

,

About Author

about author

xathrya

A man who is obsessed to low level technology.

Leave a Reply

Your email address will not be published. Required fields are marked *

Social media & sharing icons powered by UltimatelySocial