Libuv Library - Design Overview (Chinese version)

Libuv library - Design Overview

The following is a libuv Official website Design overview Chinese translation of .
http://docs.libuv.org/en/v1.x/design.html

  libuv It is a cross platform support library , Originally, it was just for Node.js And write . It is asynchronous around event driven I/O Designed for modeling .

   The library provides more than just in different I/O Simple abstraction on polling mechanism , and ”handles“ and ”stream“ The appearance of is sockets And other entities provide a more advanced abstraction . There are also cross platform I/O More functions such as file and thread functions .

   Here is a chart , Explain the composition libuv And their relationship with the corresponding subsystems ：

TIPS：

The following is an explanation of the above chart , Reprinted to ：https://toutiao.io/posts/9ucbgr/preview

   It is divided into two parts from left to right , Part is with NetWork I/O Related requests , The other part is made up of FIle I/O、DNS Ops as well as User code Composed request . As you can see from the diagram , about NetWork I/O and File I/O For each type of request represented , The underlying support mechanism of asynchronous processing is completely different . about NetWork I/O Related requests , according to OS Different platforms , The underlying support mechanism of different pairs , Such as Linux Upper use epoll,OSX and BSD Class system uses kqueue,SunOS It uses event ports as well as Windows It uses IOCP Mechanism . And for File I/O For the representative's request , Then use Thread pool. utilize Thread pool To realize asynchronous request processing , In all kinds of OS Can get good support on .

   In the article ：https://blog.libtorrent.org/2012/10/asynchronous-disk-io/ For disk I/O,Libuv Why should the team choose thread pool The mechanism of . Basically, the reason is that the coding and maintenance complexity is too high 、 Supportable API Too few and poor quality 、 Weak technical support , While using thread pool These problems are well avoided . This is a very interesting article , It can be seen from it that libuv At that time, the team made various researches and attempts to achieve cross platform asynchronous compatibility .

Handles and requests

  libuv combination event loop Two abstractions are provided for users , Namely handles and requests.

  Handles Represents the long-term survival object , Be able to handle specified events during active periods . such as ：

• Every time an event is polled , Active prepare handle All callback events will be called .
• Every time a new connection comes ,TCP Server side handle The connection request callback will be called .

  requests Usually refers to short-term survival operation . These operations are all through handle Realized ,write requests It's through handle To write data , Or no handle You can also write data .getaddrinfo requests Don't need to, handle, It runs directly on loop On .

I/O polling

  I/O（ Or events ） Polling is libuv The core of . It constitutes all I/O operation , It means that it is single threaded .libuv Yes, you can run multiple event loop Of , Just for each event loop Just create a thread （ That is, multiple event polling means multithreading ）.libuv The event loop of （ It mainly refers to polling and handle dependent API） yes Thread unsafe Of . Unless otherwise stated .

   This event loop It follows the very popular single thread asynchronous I/O Model ： be-all （ The Internet ）I/O Are based on non blocking socket To achieve , And these socket Polling is done using the best mechanism available on a given platform , such as Linux On the platform epoll Model 、OSX and BSD Class system uses kqueue、SunOS The system uses event ports and Windows The platform uses IOCP. As part of event polling , The loop will block waiting socket I/O Incident . Has been added to the polling mechanism socket I/O The callback event of the event will be in socket Conditions （ Can be read / Writable condition ） Called when triggered , Thus making handle Able to read and write data , Or perform I/O operation .

   In order to better understand the operation mechanism of event polling , The following figure illustrates all stages of circular polling ：

1. to update loop The timestamp . At the beginning of each event poll ,loop Will cache the current time . This is to reduce the number of time-dependent system calls .
2. If loop Still active , So let's continue polling , Otherwise we exit polling . So how to judge loop Be active ？ as long as loop There are also active and quoted handle、 Active request、 Closing handle, It's thought that loop Still active .
3. All expired timers are executed . All the time has passed loop Do not call the corresponding callback event in the active timer of the timestamp .
4. pending The callback event of is called . Most of the I/O The callback event is in I/O Called immediately after polling ; But those who need to delay to the next round of event polling in the last event polling I/O Callback , That's when it's called .
5. idle handle The callback event of is called . In each event poll , Active idle handle Will be run .
6. prepare handle The callback event of is called .prepare handle The callback of is in I/O Called before polling .
7. Calculate the timeout of polling . Blocking I/O Before ,loop You need to calculate how long it should block . The rules for calculating the timeout are as follows ：
   • Timeout set to 0, If loop In order to UV_RUN_NOWAIT mode .
   • If loop Has stopped （ call uv_loop() event ）. Timeout set to 0.
   • If there is no active handle perhaps request. Timeout set to 0.
   • If there is a need to delay closing handle. Timeout set to 0.
   • besides , If there is an active timer , The timeout is set to the time closest to the timer , Otherwise, the timeout will be infinite .
8. I/O Of loop modular . here , Within the duration calculated in the previous step , The cycle will be blocked during this time . In the process , All that are monitoring the given file descriptor I/O dependent handles Will call their callback events at this time .
9. Call check handle The callback event for . Check handle The callback event of is in I/O Called after polling .check handle and prepare handle formal loop The equivalent part of .
10. The close callback is called . If handle The shutdown is due to the call uv_close(), Then the close callback event will be called .
11. In particular , If loop In order to UV_RUN_ONCE Mode for polling , stay I/O After polling, there may not be I/O Callback called . But the callback event of the timeout timer will be called .
12. End of poll , If loop The mode of operation is UV_RUN_NOWAIT perhaps UV_RUN_ONCE, So at this time uv_run() It will return the result , If loop The mode of operation is UV_RUN_DEFAULT, Then the next poll will take place .

TIPS：libuv Use thread pools to make asynchronous files I/O Operation becomes possible , But the Internet I/O Throughout The thread that executes each loop in a single thread .

Be careful , Although different platforms have different polling mechanisms , however libuv stay Unix and Windows The system maintains a consistent operating mode .

file I/O

   And NetWork I/O Different ,libuv There are no platform related files I/O Mechanisms can depend on , So the current method is to deal with blocking in the process pool I/O File operations .

   Want to understand cross platform I/O Design of documents , May refer to ：https://blog.libtorrent.org/2012/10/asynchronous-disk-io/

  libuv Currently, a global thread pool is used , All loops can be queued . At present, there are three types of operations running on the thread pool ：

• File system operations .
• DNS function （getaddrinfo and getnameinfo）
• The code written by the user passes uv_queue_work() function .