设计概览

libuv 是一种支持跨平台的网络库，最初是为了NodeJS作为某个模块实现的，主要基于事件驱动的I/O 模型设计的。

这个库不仅仅对不同的I/O polling 机制提供简单的抽象。 handles 和 sreams对scokets和其他的实体提供更高层的抽象，而且还支持跨平台文件I/O和线程的功能。

下面有个图，展示了libuv的不同组成部分和他们分别属于那个系统。

Handle和requests

libuv为用户提供了两个可以使用的抽象，结合事件循环：handles和request。
Handles代表一个持久对象，存活期间可以执行一系列确定的操作。例如：
o 当一个准备好的handle在存活的时候，每次循环迭代获得一次回调函数的回调
o 一个TCP的server

handle在每次有新链接的时候都会获得一次连接回调。
而Request代表一个短期操作。
这些操作可以给予handle来实现。 写请求用来在handles上写数据，或者标志：getaddrinfo不需要一个handle直接在loop中运行。

I/O 循环

I/O 循环是libuv的核心部分。它建立起IO操作的所有内容。并且它被绑定在一个单线程上。如果你想运行多个时间循环只需要在不同的线程里面运行就可以了。libuv的事件循环（其他的API可以引入事件循环和handles）不是线程安全的除非另有说明。
event事件循环采用单线程异步I/O的方法。所有的网络I/O是非阻塞的方式执行的，异步的处理方式也是操作系统中最好的方式。linux下用的epoll, OSX和其他的BSD用的是kqueque，在SUNOS用的是event ports，而windows上用的是IOCP。作为循环迭代的一部分，循环将会阻塞等待已经被poll的I/O活动 。当套接字上的条件显示可读或者可写或者其他的操作的时候，回调将会被触发。

为了更好的理解事件循环是怎么工作的。下面的这张图展示了循环迭代的所有阶段。

解释一下上面的那张图

1. 更新循环概念中'now'事件循环在事件循环开始的时候缓存当前的时间以减少时间相关的系统调用。
2. 循环存活迭代开始，都在循环立刻退出。所以什么时候后循环被认为是在存活呢。如果一个循环当中有活动， ref’d请求（不知道咋翻译），活跃的请求，或者正在关闭的handle，就认为他是火存活的。
3. 由于计时器正在运行。在循环的当前概念获得他们的回调的时候所有的计时器被调度一次。
4. pending的callbacks被调用。所有的I/O callbacks大多数情况下在polling I/O
   之后正好被调用。也有些情况在调用的时候被推迟到下一次迭代。其实上一次的迭代将任何的I/O调用推迟就会出现这种情况。

5.idlehandle被调用。尽管这是个不幸的名字，但是idle handle在每次loop迭代都会调用，当然前提是loop存活。
6.接下来 Prepare handle被调用。 Prepare handles在loop被I/O阻塞之前恰好被调用。

1. poll 是否超时被计算。在因为I/O被阻塞之前计算它应该被阻塞多久。超时规则的计算如下：
   1）如果循环以UV_RUN_NOWAIT 标志运行的，，等待时间应该为0 2）如果循环将会停止（uv_stop被调用），超时时间是0. 3）如果没有活动的handles和request，超时时间是0 4）如果没有idlehandle活动漫画。超时时间是0 5）如果没有任何的handle期望结束，超时时间是0 6）如果以上没有任何一个条件满足，取最近的时间计时器，否则设为无穷大。
2. 循环因I/O阻塞。这里循环将会因上一步中I/O计算而阻塞。这里所有管理读写或其他操作的文件描述符的相关handle将得到调用。
3. check handle 被调用。 check handles恰好在loop阻塞之前恰好被调用。check handles和prepare handles是对应的。
4. close handles 被调用。 如果一个handle 被调用uv_close时候被关闭。close回调会被调用
5. 特别情况下loop可以以UV_RUN_ONCE调用。在I/O阻塞之后没有I/O调用被触发也是可能的。但是有些时间已经过去了，所以一些计时器已经到期了。这些计时器获得调用。
   12.迭代停止。如果loop运行flag是 UV_RUN_NOWAIT 和 UV_RUN_ONCE迭代将会结束并且Uv_run() 将会返回。如果循环以UV_RUN_DEFAULT运行， loop存活的话会从头开始运行，否则就结束。

特别的：libuv利用线程池让异步 I/O操作变得可能。所以网络I/O 总是在单线程，每个loop是个线程。

文件I/O

不像网络 I/O， 文件I/O没有平台特殊性的文件I/O基本元可依赖。当前的方案是在线程池中运行阻塞的I/O操作。
libuv用的全局线程池，所有的事件循环都可以在上面工作。有三种类型的操作在池上运行。
文件系统操作
DNS函数
用户通过uv_queue_work()声明的代码

看一下线程池的调度部分，其实线程池大小很有限。