Blog.csdn.net/gx_1983/art…

 

Official documents link to dot dot dot dot

 

Github.com/luohaha/Chi…

Luohaha. Making. IO/Chinese – uvb… Chinese tutorial

Github.com/nikhilm/uvb…

Github.com/nikhilm/uvb… Form a complete set of source code

C++ package libraries are as follows:

Sourcey.com/libuv-cpp-w… — – > github.com/sourcey/lib…

github.com/larroy/uvpp

Github.com/derekdai/uv…

1. An overview of the

Libuv is an asynchronous IO library that supports multiple platforms. It was developed primarily for Node.js, but can also be used with Luvit, Julia, Pyuv, and other software.

Note: If you find a bug in this software, please submit itpull requestsTo help us fix this bug to improve software quality.

2. The characteristics of

1. All features of event loops based on epoll, KQueue, IOCP and Event ports.

Asynchronous TCP and UDP Sockets.

3. Asynchronous DNS decision making.

4. Asynchronous file and file system operations.

5. File system events.

6. TTY controlled by ANSI Escape code.

7. Interprocess communication (IPC) with Socket sharing, using Unix domain Sockets or Named Pipes (on Windows).

8. Child processes.

Thread pools.

10. Signal processing.

11. High resolution clock.

12. Synchronization Primitives

3. Download

Libuv fromhereDownload.

4. Install

Installation instructions are available atREADMEFound.

5. Upgrade

Different versions of the program migration reference is as follows:

Migrate from 0.10 to 1.0.0 

6. Document

6.1 Design overview 

Libuv is a cross-platform library designed around an event-driven asynchronous I/O model.

Not only does the library provide an abstraction for the different I/O polling mechanisms, but the Handles and Streams mechanisms also provide a higher-level abstraction for sockets and other entities. The library also provides cross-platform file I/O operations and threading capabilities.

The figure below shows the different components of Libuv and their associated subsystems.

  1. The lowest level of socket-related operations are epoll/kqueue and Event ports. These operations are based on Unix like systems. Uv_io_t structures are abstracted from the specific apis of these systems to provide unified UNIX-like sockets and event interfaces.

  2. Epoll -> Linux kernel; Kqueue -> After freeBSD 4.1; Event ports-> seems to be used on Linux as well.

  3. IOCP is an asynchronous I/O event model that is unique to Windows and is supported by Libuv. That’s where libuv is better than Libev.

  4. Libuv also supports thread pooling.

  5. On top of the above low-level abstractions, Libuv provides a higher level of abstraction, with abstracted TCP/UDP/TTY/PIPE interfaces.

  6. These interfaces provide file I/O operations, DNS operations, and so on.

  7. Users can implement their own applications based on all of the above abstract interfaces.

    Handle and request

    Libuv provides users with two ways to work with event loops: a handle and a request.

    Handles represent a long-running object that can perform specific operations when active. For example, a prepare handle that is active can call its callback once per loop. A TCP server handle invokes its connection callback function every time a new connection is created.

    A request generally stands for a short operation. These operations can be applied to handles. Write requests are used to write data on handles; There are some exceptions, such as the getAddrInfo request that does not require a handle and is executed directly in a loop.

    I/O cycle

    The I/O loop, or event loop, is a core part of libuv. The I/O loop establishes the execution environment for all I/O operations. The I/O loop is bound to a thread. We can run multiple time loops as long as each one is running on a different thread. Libuv event loops are not thread-safe, so all apis and handles that contain event loops are not thread-safe.

    The event loop follows the most common single-threaded asynchronous I/O approach: all I/O or network operations are executed on a non-blocking socket that uses a pooled poll mechanism based on the platform: Use epoll on Linux, kqueue on OSX and other BSD platforms, Event Ports on sunOS, and IOCP on Windows. As part of the iteration of the loop, the loop blocks to wait for I/O activity on the socket that has been added to the socket firing practice. Once these conditions are met, the state of the socket changes so that the loop is no longer blocked and the handle can read, write, and perform other expected I/O operations.

    To better understand how the event loop operation works, the following diagram shows all the phases of a loop iteration.

    1. The “now” in loop is updated to the current time. The event loop caches the current time tick count at the beginning of the loop to reduce the number of time-dependent system calls.
    2. If the loop is alive, an iteration has started, otherwise the loop exits immediately. So, when is a loop considered alive? The answer is that a loop is considered alive if it contains active and ref ‘d handles, active requests or closed handles.
    3. The Due timer runs.
    4. The pending callback is invoked.
    5. The idle handle callback is invoked.
    6. The prepare callback handle is invoked.
    7. Calculate poll timeout.
    8. Loop blocking.
    9. Call the check handle.
    10. Call the close handle.
    11. Special case run.
    12. A loop iteration ends. ** Note: Libuv uses thread pool technology to make asynchronous file I/O operations possible, but for networks IO can only be performed in a single thread, the loop thread. 六四屠杀