Library-LIBUV: Overview

LIBUV is Node's new cross-platform abstraction layer for abstracting Windows IOCP and Unix Libev. The author intends to include in this library the differences of all platforms.

Feature:

    non-blocking TCP sockets
    non-blocking named pipes
    UDP
    Timer
    sub-processes generate asynchronous
    DNS
    asynchronous file system implementations via Uv_getaddrinfo api:uv_fs_* High resolution time: Uv_hrtime
    Running Program path lookup: Uv_exepath
    thread pool Scheduler: Uv_queue_work
    TTY-controlled ANSI escape code: uv_tty_t
    File system events now support INotify, READDIRECTORYCHANGESW, and Kqueue. The event port will soon be supported: uv_fs_event_t

    inter-process IPC with socket sharing: UV_WRITE2

 

supported Platforms:

    Microsoft Windows operating system, such as Windows XP SP2. Use Visual Studio or MinGW
    to build Linux 2.6 using the GCC toolchain
    for MacOS using the GCC or XCode toolchain
    for Solaris 121 or later, using the GCC toolchain

Preface

This book consists of a series of libuv tutorials, LIBUV is a high-performance event-driven library that encapsulates some of the underlying features of the Windows and Unix platforms, providing a unified API for developers.

This book is intended to cover the main features of LIBUV and is not a complete guide to each API and data structure within LIBUV, and the official documentation official LIBUV documentation can be found directly in the header file provided by the LIBUV source.

The book has not been completed, some chapters may not be complete, but I hope that while I continue to improve the book, you can also benefit from:-) who is the book written for?

If you are reading this book, you may be: system developers, writing some underlying applications such as daemons (daemons), Web service programs, or clients, and you find that LIBUV's event loops are appropriate for your scenario, so you decide to use LIBUV. The author of a node. JS module that decides to use some of the synchronous or asynchronous APIs of the C + + encapsulation system platform and exposes it to javasript, you can use only libuv in the node. JS context, but you also need to refer to other resources because this book does not include v8/no De.js related content.

This book assumes that you have a certain understanding of C language. background

node. JS was originally launched in 2009 as an execution environment that lets Javascript code out of the browser, LIBUV uses Google's V8 execution engine and Marc Lehmann's Libev. node. JS blends the event-driven I/O model with the programming language (Javascript) that fits the model, and as node. JS is becoming more popular, node. JS developers realize that node. JS should also work under the Windows platform, but l Ibev can only be run in a Unix environment. The mechanism for kernel event notifications on Windows platforms, such as Kqueue (FreeBSD) or (e) poll (Linux), is IOCP, LIBUV based on the characteristics of different platforms (Unix platform is Libev, Windows platform is IOCP) to the upper The Libev API-based abstraction is provided, although Libev dependencies in the node-v0.9.0 version of LIBUV have been removed, see: Libev has been removed LIBUV directly interacting with the Unix platform. This book code

All of the code in this book can be obtained on Github, clone/download the source of the book, and then go to the code/directory to execute the example of make compile book. The code in the book is based on the node-v0.9.8 version of the LIBUV, in order to facilitate the reader to learn, the source of the book also comes with the corresponding version of the LIBUV, you can find the source code in the libuv/directory, LIBUV will be compiled in the example of your book is automatically compiled.

LIBUV Foundation

The LIBUV employs an asynchronous (asynchronous), event-driven (Event-driven) programming style, whose main task is to provide a set of event loops and callback functions based on I/O (or other activity) notifications for the driver, LIBUV provides a set of core toolset, such as timers, non-blocking network programming support, asynchronous access to file systems, sub-processes, and other functions. event Loop (loops)

In the event programming model, applications typically focus on specific events and respond to them after they occur. Collecting events or monitoring other event sources is LIBUV's responsibility, and programmers only need to register callback functions for the events of interest, and LIBUV will invoke the appropriate callback function after the event has occurred. As long as the program does not exit (killed by the System Manager), the event loop will always run, and the following is the pseudo-code of the event-driven programming model:

While there was still events to process:
    e = Get the next event if there was a callback associated with E: Call the
        Callback

Examples of the event-driven programming model are: The file is ready to write data. There is data readable on a socket. The timer has timed out.

The event loop is encapsulated by the Uv_run function, which is usually called at the end of programming with LIBUV.

The most basic activity of a computer program is the processing of input and output, not a large number of numerical computations, and the problem with using traditional input and output functions (read, fprintf, etc.) is that they are all blocked. Writing data to disk or reading data from the network consumes a lot of time, and the blocking function does not return until the task is completed. During this period your program did nothing and wasted a lot of CPU time. For the pursuit of high performance programs, other activities or I/O operations are carried out as far as possible to keep the CPU from blocking.

The standard solution is to use threads, where each blocking I/O operation is started in a separate thread (or thread pool), and when the blocking function is called, the processor can dispatch another thread that really needs the CPU to perform the task.

LIBUV uses a different approach to blocking tasks, asynchronous and non-blocking. Most modern operating systems provide event notification functionality, for example, when a read reads a network socket is called, the program blocks until the sender eventually sends the data (read returns). However, an application can require the operating system to monitor sockets and register event notifications on the socket. The application can view the events it monitors and obtain data, if any, at the appropriate time. The whole process is asynchronous, because the program focuses on the event it is interested in at some point and acquires (uses) the data at another time, which is also non-blocking, because the process can also handle additional tasks. The Libuv event loop is well matched to the model because operating system events can be considered as another LIBUV event. The non-blocking approach guarantees that the other events will be processed as soon as possible [1].

Note

How I/O operates in the background is not what we care about, but because of how our computer hardware works, threads are the most basic unit of execution for the processor, and thread as the basic unit of the LIBUV and operating system typically runs background/worker threads, or uses non- Blocking mode to take turns performing tasks. Hello World

With the basic knowledge above, we will write a simple LIBUV program. The program does not do anything specific, but simply launches an event loop that will exit.

#include  #include  int main () {
    uv_loop_t *loop = Uv_loop_new ();

    printf ("Now quitting.\n");
    Uv_run (Loop, uv_run_default); return 0;
}

When the program starts, it exits directly because you have no event to handle. We can use LIBUV to provide a variety of APIs to inform LIBUV of events of interest to us. default event loop for Libuv

LIBUV provides a default event loop that you can uv_default_loop to get the event loop, and if you have only one event loop in your program, you should use the default event loop that Libuv gives us.

Note

node. JS uses the default event loop as its main loop, and if you're writing node. js bindings, you should be aware of this point. Monitor (watchers)

LIBUV monitors specific events through a monitor (watcher), typically a package similar to the uv_type_t structure, where type represents the purpose of the monitor, and libuv all of the monitor types are as follows:

typedef struct UV_LOOP_S uv_loop_t;
typedef struct UV_ERR_S uv_err_t;
typedef struct UV_HANDLE_S uv_handle_t;
typedef struct UV_STREAM_S uv_stream_t;
typedef struct UV_TCP_S uv_tcp_t;
typedef struct UV_UDP_S uv_udp_t;
typedef struct UV_PIPE_S uv_pipe_t;
typedef struct UV_TTY_S uv_tty_t;
typedef struct UV_POLL_S uv_poll_t;
typedef struct UV_TIMER_S uv_timer_t;
typedef struct UV_PREPARE_S uv_prepare_t;
typedef struct UV_CHECK_S uv_check_t;
typedef struct UV_IDLE_S uv_idle_t;
typedef struct UV_ASYNC_S uv_async_t;
typedef struct UV_PROCESS_S uv_process_t;
typedef struct UV_FS_EVENT_S uv_fs_event_t;
typedef struct UV_FS_POLL_S uv_fs_poll_t;
typedef struct UV_SIGNAL_S uv_signal_t;

The structure of all monitors is uv_handle_t "subclass", which is called a handle (handlers) in both LIBUV and this article.

The monitor is set by the appropriate type of initialization function, as follows:

Some monitors initialize the function's first parameter as a handle to the event loop.

The monitor then sets the event callback function and listens for the event by invoking the following type of function:

And stop listening should call the following types of functions:

The callback function is called when the Libuv listener event occurs. Application-specific logic is usually implemented in callback functions, for example, the timer callback function is called after a timeout event, and when the callback is called, the associated parameters are related to a specific type of event, for example, the IO Monitor's callback function will receive data read from the file after an IO event occurs. idling (idling)

Next we use the example to tell the monitor's usage. example, the idling monitor callback function is repeatedly called, of course there are some deep-seated language, we will be further discussed in the Toolset, but now we just skip the specifics. We just used a idling monitor callback to look at the life cycle of the monitor, and through the example we can also learn: Because the monitor is set, so call Uv_run () is the program will block, the idling monitor will stop when the counter reaches the set value (monitoring), Uv_run () Will exit because there is no active monitor in the program at this time.

#include  #include  int64_t counter = 0; void Wait_for_a_while (uv_idle_t* handle, int status) {
    counter++; if ( Counter >= 10e6)
        uv_idle_stop (handle);
} int main () {
    uv_idle_t idler;
    Uv_idle_init (Uv_default_loop (), &idler);
    Uv_idle_start (&idler, wait_for_a_while);

    printf ("idling...\n");
    Uv_run (Uv_default_loop (), uv_run_default); return 0;
}

File System

Simple file read and write is through the uv_fs_* function family and associated with it