Libuv in Node.js

Node.js relies on various dependencies under the hood for providing various features.

• V8
• libuv
• llhttp
• c-ares
• OpenSSL

Libuv is one of them, let’s discuss libuv in detail.

libuv: libuv is a C library originally written for Node.js to abstract non-blocking I/O operations. 

• Event-driven asynchronous I/O model is integrated.
• It allows the CPU and other resources to be used simultaneously while still performing I/O operations, thereby resulting in efficient use of resources and network.
• It facilitates an event-driven approach wherein I/O and other activities are performed using callback-based notifications.

Example: If a program is querying the database, the CPU sits idle until the query is processed and the program stays at a halt, thereby causing wastage of system resources. To prevent this, libuv is used in Node.js which facilitates a non-blocking I/O.

It also has mechanisms to handle services like File System, DNS, network, child processes, pipes, signal handling, polling, and streaming.
To perform blocking operations that can’t be done asynchronously at OS level, libuv also includes a thread pool to distribute CPU loads. 

• What is a thread pool?
  

Libuv assigns tasks to a pool of worker threads. However, all callbacks that occur on task completion are executed on the main thread. 
Note: After Node 10.5 worker threads can also be used to execute JavaScript in parallel. Libuv uses 4 threads by default, but can be changed using the UV_THREADPOOL_SIZE 

process.env.UV_THREADPOOL_SIZE = 5

Features of libuv:

• Full-featured event loop backed by epoll (Linux), kqueue (OSX), IOCP (Windows), event ports (SunOS).
• Asynchronous TCP (net module) and UDP (dgram module)
• Asynchronous DNS resolution (used partly for the dns module)
• Asynchronous file, file system operations & events (fs module)
• ANSI escape code controlled TTY
• Thread pool and Signal handling
• Child processes
• High-resolution clock
• Threading and synchronization primitives.
• Inter-Process Communication using sockets and Unix domain sockets (Windows)
  

Event or I/O loop: Event or I/O loop uses a single threaded asynchronous I/O approach, hence it is tied to a single thread. In order to run multiple event loops, each of these event loops must be run on a different thread. It is not thread-safe by default with some exceptions. 

Libuv maintains an Event queue and event demultiplexer. The loop listens for incoming I/O and emits event for each request. The requests are then assigned to specific handler (OS dependent). After successful execution, registered callback is enqueued in event queue which are continuously executed one by one. 
Note: The current time required during entire process is cached by libuv at beginning of each iteration of loop to minimize frequent system calls.

Example: If a network request is made, a callback is registered for that request, and the task is assigned to the handler. Until it is performed other operations carry on. On successful execution/termination, the registered callback is en-queued in the event queue which is then executed by the main thread after the execution of previous callbacks already present in the queue.

It uses platform-specific mechanisms as mentioned earlier to achieve the best compatibility and performance epoll (Linux), kqueue (OSX), IOCP (Windows), event ports (SunOS).

File I/O: File I/O is implemented in libuv using a global thread pool on which all loops can queue work. It allows disk to be used in an abstracted asynchronous fashion. It breaks down complex operations into simpler operations to facilitate async-like behavior. 

Example: If the program instructs to write a buffer to a specific file, in normal situations, the I/O will be blocked until the operation is successful/terminated. However, libuv abstracts this into an async manner by putting an event notification which would notify about operations success/failure after it is finished, until then the other I/O operations can be performed hassle-free. 
Note: Thread-safety is not assured by libuv (with few exceptions)

Unlike event loop, File I/O uses platform-independent mechanisms. There are 3 kinds of async disk APIs that are handled by File I/O:

1. linux AIO (supported in kernel)
2. posix AIO (supported by linux, BSD, Mac OS X, solaris, AIX, etc)
3. Windows’ overlapped I/O

Benefits:

• Disk operations are performed asynchronously.
• High level operations can be broken down to simpler disk operations which facilitate rectifying the information.
• Disk thread can use vector operations like readv & writev allowing more buffers to be passed.

Reference: http://docs.libuv.org/en/v1.x/design.html