LIBUV Chinese Programming Guide---LIBUV Foundation

Original from: http://www.cnblogs.com/haippy/archive/2013/03/15/2962202.html

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 to the staff, LIBUV provides a set of core toolset, such as timers, support for non-blocking network programming, asynchronous access to file systems, child processes, and other features. Events Loop (event loops)

In the event programming model, an application usually focuses on certain events and responds to them after they occur. While collecting events or monitoring other event sources is LIBUV's responsibility, programmers only need to register callback functions for events of interest, and LIBUV will call the corresponding callback function after the event occurs. As long as the program does not quit (killed by the system administrator), the event loop usually runs, following is the pseudo code for the event-driven programming model:

While there are still events to process:
    e = Get the next event
    if there are a callback associated with E:
        call The callback

An example of an event-driven programming model is the following: 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 invoked at the last minute when 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 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, The blocking function does not return until the task is complete, and during this time your program does nothing and wastes a lot of CPU times. For high-performance programs, other activities or I/O operations are done to keep the CPU from blocking.

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

LIBUV uses another way to handle blocking tasks, that is, asynchronous and non-blocking. Most modern operating systems provide event notification, for example, when a read reads a network socket, the program blocks until the sender finally sends the data (read returns back). However, an application can require the operating system to monitor sockets and register event notifications on sockets. The application can view the events it monitors and fetch the data (if any) at the appropriate time. The whole process is asynchronous , because the program pays attention to events of interest 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 works well with the model because operating system events can be considered as a different kind of LIBUV event. Non-blocking methods can guarantee that the other events will be processed as soon as possible [1].

Note

How I/O is run in the background is not our concern, but because the way our computer hardware works, threads are the most basic execution unit of the processor, thread as the basic units of the, LIBUV and operating systems typically run background/worker threads, or use non- Blocking way to perform tasks in turn. Hello World

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

#include <stdio.h>
#include <uv.h>

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

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

    return 0;
}

The program will quit immediately after it starts, 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. libuv default loop of events

LIBUV provides a default event loop where you can get the event loop by Uv_default_loop, and if you have only one event loop in your program, you should use the default event loop that LIBUV provides for us.

Note

Node.js uses the default event loop as its main loop, and if you're writing a node.js binding, you should be aware of that. Monitor (watchers)

LIBUV monitors a particular event through a monitor (watcher), which is typically a package similar to the uv_type_t structure, type represents the purpose of the monitor, LIBUV all 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 a "subclass" of uv_handle_t, which is referred to as a handle ( handlers ) in both LIBUV and this article.

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

The first parameter of some monitor initialization function is the handle of the event loop.

The monitor then sets the event callback function and listens for the corresponding event by calling a function of the following types:

To stop listening, you should call the following types of functions:

The callback function is invoked when the LIBUV listener event occurs. Application-specific logic is usually implemented in a callback function, for example, the timer callback function is invoked after a timeout event, and when a callback is called, the relevant parameters passed in are related to a particular 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'll talk about the use of monitors with examples. In the example, the idling monitor callback function is repeatedly called, of course there are some deep language, we will discuss it further in the toolset, but now we just skip the specifics. We just used an idle monitor callback to look at the monitor's lifecycle, and we can see from the example that because the monitor is set, the call to Uv_run () is blocked and the idling monitor will stop when the counter reaches its set value (monitor), Uv_run () Will quit because there are no active monitors in the program at this time.

#include <stdio.h>
#include <uv.h>

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;
}