Node.js Reactor Pattern & Event Loop | How Node.js Supports Concurrency | Learn Node.js

by now almost everyone knows that node. js uses an event Loop however knowing how this event Loop actually works is another story in reality node. js achieves its concurrent nature due to something known as the reactor pattern however this fact usually creates more questions than answers what is the reactor pattern what makes it so special is it something complicated when learning about the inner workings of node. js confusion often beats Clarity not anymore in today's video we will chop our way through the tickets of confusion and learn about the node. js reactor pattern and how it makes the event look possible node. js uses JavaScript since JavaScript is single threaded node. js is also single threaded at least on a high level but JavaScript and by extension node. js can still handle concurrency the secret to this concurrent behavior is the event Loop like most other programming languages JavaScript also relies heavily on functions in fact in JavaScript functions are first class citizens basically you can do a lot with functions in JavaScript such as assigning functions to variables passing functions as arguments returning a function from another function's invocation store functions in other data structures predictably functions can also call other functions when one function calls another function it adds frames to the call stack basically with every call this stack keeps getting taller recursive functions can make this stack extremely tall leading to an eventual collapse depending on the maximum call stack size nevertheless JavaScript has one major difference from other programming languages when it comes to the call stack in many languages the entire request cycle correlates to a single stack this stack grows as the request is received reaches a particular height shrinks as the stack unwinds and ultimately disappears when the request is finished on the other hand JavaScript does not constrain itself to run within a single call stack throughout this lifetime however since JavaScript is single threaded only one stack can run at a given time check out this example running this particular program will result in an output like this the figure visualizes how this program manages the call stack notice there are two separate Stacks but neither of them overlaps each other during the same time the a functions call stack is the first to run whereas the X function is added to the queue even though the set timeout function specifies that X function should run 0 milliseconds from now the execution does not start immediately due to the single threaded nature of JavaScript the event Loop checks for new work only when the current stack is complete if a function was a long running process the wait time for X function would increase further a function that takes a long time to run blocks the event Loop the application will be stuck processing slow synchronous code and the event Loop will not be able to process further tasks therefore it is easy to conclude that in order to achieve concurrency we need to avoid slow synchronous code however this is easier said than done input output is one of the fundamental operations of a computer system also it happens to be the slowest accessing the ram is in the order of nanoseconds accessing a disk is even slower in the order of milliseconds the bandwidth shares the same story Ram has a transfer rate in the order of GBS per second while disk and network can vary from mb per second to GB per second moreover input output also involves the human factor the biggest delay in an application often comes from waiting for user input for example Mouse clicks and keystrokes these delays can be many orders of magnitude slower than disk access or even the network while input output is not computational heavy it adds a delay between the moment of request and the moment the operation completes and this is the reason it is so difficult to avoid slow synchronous code while dealing with slow and blocking i o operations so how do programming languages achieve concurrency many use multi-threading in traditional blocking i o programming the function call corresponding to an input output request will block the execution until the operation completes this can go from a few milliseconds for disk access to even minutes in case the data is generated from a real user pressing some key it goes without saying that a web server that uses blocking IO will not be able to handle multiple connections within the same thread each input output operation will block the processing of any other connection therefore to achieve concurrency web servers start off a new thread for each concurrent connection when a particular thread blocks for an i o operation other requests will not be impacted as those requests have their own separate threads hence the name multi-threading is a great concept but unfortunately a thread is not cheap in

terms of system resources it consumes memory and leads to context switches also many times a thread ends up in idle mode while waiting for the result of an IR operation this is quite wasteful in terms of resource utilization it is quite obvious that having a long running thread for each connection is not the best approach to improve efficiency most modern Operating Systems Support a mechanism known as non-blocking IO as the name suggests this type of input output does not block the execution the system called to access a resource always returns immediately without waiting for the data to be read or written if no results are available when the call is made the function simply returns a predefined constant so how is the data actually accessed using non-blocking input output we use busy weighting essentially busy waiting is nothing but actively polling the resource in a loop till it returns some actual data while busy waiting makes it possible to handle different resources in the same thread it is still significantly inefficient polling algorithms usually waste a lot of CPU time most likely the loop will end up consuming precious CPU only for iterating over resources that are unavailable most of the time busy waiting is not an ideal technique for handling non-blocking resources however most modern operating systems provide another mechanism to support concurrent and non-blocking resources it is called the event demultiplexer you can also call it the event notification interface there are three important steps that drive the event demultiplexing process first the resources are added to a watch list each resource has a specific Associated operation such as read or write the event demultiplexer is assigned this particular watch list of resources along with the callbacks the demultiplexer makes a synchronous and blocking call for any events generated from the watched resources when the demultiplexer eventually returns from the blocking call it has a new set of events available for processing each event returned by the event demultiplexer is processed by the application callback Methods at this point the resource is guaranteed to be ready to read and not blocked during the operation when all the events are processed the demultiplexer will again make a blocking request for the next set of events this process is also known as the event Loop and forms the basis of concurrency in node. js as you might have noticed the event demultiplexer makes it possible for a single thread to handle multiple requests no need for busy weight no need for multiple threads a single thread is enough with very little idle time in this approach tasks are spread over time instead of being spread across multiple threads having trudged our way through all the explanation we are now in a great position to understand the node. js reactor pattern essentially the reactor pattern is simply a specialization of the event demultiplexer check out this node. js reactor pattern illustration in all its Glory based on this picture we can Now understand the inner workings of the node. js reactor pattern in six easy steps in Step 1 the application generates a new input output operation by submitting a request to the event D multiplexer along with the request the application also provides a Handler or a callback this is like telling the demultiplexer whom to contact once the job is done the call to the demultiplexer is non-blocking and the control returns back to the application immediately in Step 2 the event demultiplexer does its whole watchless thing and waits for events from the input output resources where a set of i o operations are completed the event D multiplexer pushes the corresponding events into the event queue in step 3 the event Loop iterates over the items in the event queue important point to note here is that the event queue is not just one queue but multiple queues that are processed in different phases in Step 4 the event Loop triggers the Handler for each event it was told about this Handler by the event demultiplexer in Step 2. In step 5 the handlers are part of the application code once a Handler runs a couple of things can happen the Handler may give back the control to the event Loop check the path 5A however the Handler might request for new asynchronous operations path 5B the 5B path will result in new operations being inserted to the event demultiplexer in Step 6 when the event queue is empty the loop will block again on the event demultiplexer which will start another cycle if we had to be absolutely brief the reactor pattern handles IO by blocking until new events are available from a set of watched resources when events become available it dispatches each event to its

Associated Handler using the event Queue at some point the event demultiplexer will not have any pending operations and there would be no events left in the event queue when this happens the node. js application automatically exits today lib UV is the low level i o engine of node. js the entire magic of node. js reactor pattern is implemented by libuv behind the scenes libuv performs a number of important things it provides an API for creating event Loops it manages event cues it runs async i o operations it queues other types of tasks but what was the need for libuv each operating system has its own interface for the event demultiplexer such as e-pol on Linux KQ on Mac OS and iocp on Windows to make matters more complicated each i o operation behaves quite differently depending on the type of the resource and the operating system for example in Unix regular file system files do not support non-blocking operations and it is required to use a separate thread to simulate a non-blocking behavior since a node. js application can run on any platform or operating system a higher level abstraction was needed to iron out these platform specific differences this is the reason why the node. js code team created a C library known as libuv the objective of lib UV was to make node. js compatible with all major platforms and normalize the non-blocking behavior of different types of resources while the reactor pattern and libuv are definitely the Beating Heart of node. js there are still a few more components needed to power the complete platform in the way we see it check this illustration as you can see we have a few more important components other than libue there is a set of bindings for wrapping and exposing libuv and other low-level functionality to JavaScript remember libuv was written using C programming language there is also V8 the JavaScript engine developed by Google for the Chrome browser finally we also have a core JavaScript library known as node core that implements the high level node. js API together all these components form the core architecture of node. js on top of all this we have the user line modules and applications that we build using node. js the reactor pattern forms the core of node. js and yet developers don't know much about it of course it is so nicely abstracted the developers can still build useful applications using node. js even if they haven't even heard about the reactor pattern however knowing about this pattern is good in the long run as you can make better choices about your application if you understand how node. js will handle it internally nevertheless there is a lot to unpack here and we can't know about everything in one go in the next video we will look at node. js event Loop phases with a code example if this particular video was useful don't forget to press like And subscribe to the channel also share it with your friends and colleagues stay safe and see you next