Understanding the event loop in Node JS

If you've been following our Node.js guide, you know that Node is built on three fundamental foundations: Google's V8 JavaScript engine, a low-level API called libuv, and an event loop more commonly known as an event loop. These three elements work in complementarity to enable the processing of inputs and outputs in an innovative, non-blocking and asynchronous way - which is the hallmark of Node.

While the V8 engine is dedicated to interpreting JavaScript, the API provided by the libuv library allows Node developers to access the event loop. The latter is also distinct from the internal event loop of browsers (JavaScript event loop), which allows them to execute the JS.

🧑‍🎓 Vous souhaitez apprendre à utiliser NodeJS 📖 ?
Practical Node vous enseigne les bonnes pratiques NodeJS pour être opérationnel dès le premier jour !

What is the Node.js loop event?

When you run a program on your computer, you create an instance linked to that program. To this can be attached one or more threads (or execution thread), which correspond to a series of operations to be performed by the processor (CPU). The management and optimization of threads is handled by the operating system, which allocates the available resources to them at the right time.

When running a Node.js program, only one thread is created. This is where all of the code will be processed. Within this thread is generated the event loop that will decide what operation should be performed and when. To do this, the event loop communicates with the operating system's kernel (or kernel). Because modern kernels are multi-threaded, they can perform multiple operations in the background. When one of them is finished, the kernel returns the corresponding callback (the function to be executed following the operation) to Node.js to be executed later in the loop.

The event loop accessible via libuv allows to read each line of code, to interpret it, and to create an event to be executed by the thread. Each event is thus stored in a queue called the Event queue. In Node, there are actually several types of tail events that correspond to different types of events. These different queues are processed at separate times, in several successive stages which constitute the phases of the event loop.

The different phases of the Node event loop

When we launch a Node application, the event loop is initialized before the code is interpreted. After the interpretation, the event loop is started. Each iteration (called tick) of the loop goes through different phases, but a tick can only start if there are operations pending in an event queue.

Once an iteration has started and therefore entered within a tick, the event loop successively goes through the following steps.

Phase 1: timers

A timer specifies a delay after which a callback will be executed. This delay can be extended, for example if tasks performed by the operating system or the execution of other callbacks prevent the timer callback from being executed in time. When the timer expires, the timer callback is placed in an event queue, telling Node that it is ready to be executed.

When an iteration of the event loop is launched, it begins with this first phase in which Node will execute the callbacks of timers ready to be executed and placed on hold following the expiration of a setTimeout () or a setInterval () - two functions to specify a delay in JavaScript.

If each tick in the event loop begins with this phase, it is to ensure that a timer callback is executed as quickly as possible after it is put on hold.

When all of these pending timer callbacks are executed (or there are none to be executed), the event loop goes into its second phase.

Phase 2: pending callbacks

In the same way as for the first phase, Node will now come and look for callbacks pending in an event queue to execute them.

This time, it will look in the queue reserved for callbacks of system operations such as Node filesystem functions or TCP errors for example.

The event loop then moves on to the next phase, still within the same tick.

Phase 3: the interrogation or poll phase

The third step of the Node event loop is the poll phase or polling phase. This phase is more complex: during this, Node will block the event loop and wait for new events to execute them. To do this, Node will first calculate the duration of the blocking and then process the events present in the poll queue (all those not allocated in the other queues).

If the event loop enters the poll phase when no timer is scheduled, two possibilities exist:

If the poll queue is not empty, the loop will iterate over the callbacks present there and execute them one after the other until there are no more or the system limit is reached.

If the poll queue is empty and no script has been scheduled by setImmediate (), the event loop is blocked and continues to wait for new callbacks to be executed. If scripts have been scheduled by setImmediate (), the loop continues to the next step. If any timers expire, the loop returns to step 1 to process them.

Phase 4: verification or check phase

When you want to run a script asynchronously but as quickly as possible, one possible option in Node is to use the setImmediate () function. Any function passed as an argument to setImmediate () is a callback to be executed in the next iteration of the event loop.

It is in this fourth step, the verification phase or check phase that Node executes the events of this event queue. So if the loop is stuck in phase 3 and scripts have been scheduled with setImmediate (), the event loop continues through phase 4 rather than continuing to wait.

Phase 5: close callbacks

When a "close" type event is issued, for example when a socket is closed with socket.destroy (), it is placed in the event queue dedicated to this step. When the loop reaches this last phase, Node picks up the events in this queue and emits them. This step allows us to "clean up" the state of our application before starting a new iteration of the event loop.