libuv 概览

July 1, 2024

c lib

总结：libuv 是围绕事件驱动的异步 I/O 模型设计的跨平台 C 库。

libuv 的主要组件包括：

I/O 循环（事件循环）：libuv 的核心部分。为所有 I/O 操作建立上下文（即管理所有 I/O 操作），并且应与单个线程绑定（非线程安全）。
Handles：表示能够在活动状态下执行某些操作的长生命周期对象，例如 TCP 服务器 handle。
Requests：通常表示短生命周期的操作，例如写请求。

使用说明，另见 UserGuide 翻译

Design overview

libuv 是一个跨平台支持库，最初是为 Node.js 编写的。它围绕事件驱动的异步 I/O 模型设计。

该库不仅仅是对不同 I/O 轮询机制的简单抽象：'handles' 和 'streams' 提供了对套接字和其他实体的高级抽象；还提供了跨平台的文件 I/O 和线程功能等。

下图展示了 libuv 的不同组成部分及其相关的子系统：

_images/architecture.png

Handles 和 Requests

libuv 提供了两种与事件循环配合使用的抽象：handles 和 requests。

Handles 表示能够在活动状态下执行某些操作的长生命周期对象。例如：

一个 prepare handle 在每次循环迭代时调用其回调函数。
一个 TCP 服务器 handle 在每次有新连接时调用其连接回调函数。

Requests 通常表示短生命周期的操作。这些操作可以在 handle 上执行：写请求用于在 handle 上写入数据；也可以独立执行：getaddrinfo 请求不需要 handle，它们直接在循环上运行。

I/O 循环

I/O（或事件）循环是 libuv 的核心部分。它为所有 I/O 操作建立了上下文，并且应该与单个线程绑定。可以在不同的线程中运行多个事件循环。libuv 事件循环（或任何涉及循环或 handles 的 API）不是线程安全的，除非另有说明。

事件循环遵循常见的单线程异步 I/O 方法：所有（网络）I/O 都在非阻塞套接字上执行，使用给定平台上最好的机制进行轮询：Linux 上的 epoll，OSX 和其他 BSD 上的 kqueue，SunOS 上的事件端口和 Windows 上的 IOCP。作为循环迭代的一部分，循环将阻塞等待已添加到轮询器的套接字上的 I/O 活动，并触发回调以指示套接字状态（可读、可写、挂起），以便 handles 可以读取、写入或执行所需的 I/O 操作。

为了更好地理解事件循环的操作，以下图示说明了循环迭代的所有阶段：

_images/loop_iteration.png

循环的“现在”概念最初被设置。
如果循环是用 UV_RUN_DEFAULT 运行的，则运行到期的定时器。所有计划在循环的现在之前的活动定时器都会调用其回调函数。
如果循环是活跃的，则开始一次迭代，否则循环会立即退出。那么，什么时候循环被认为是活跃的呢？如果循环有活动且引用的 handles、活动请求或正在关闭的 handles，则被认为是活跃的。
调用挂起的回调。所有 I/O 回调在大多数情况下在轮询 I/O 后立即调用。但是，在某些情况下，调用此类回调会被推迟到下一次循环迭代。如果前一次迭代推迟了任何 I/O 回调，它将在此时运行。
调用 idle handle 回调。尽管名称不幸，idle handles 在每次循环迭代时都会运行，如果它们是活动的。
调用 prepare handle 回调。Prepare handles 在循环即将阻塞 I/O 之前调用其回调函数。
计算轮询超时。在阻塞 I/O 之前，循环会计算应阻塞多长时间。计算超时的规则如下：
- 如果循环是用 UV_RUN_NOWAIT 标志运行的，超时为 0。
- 如果循环即将停止（调用了 uv_stop()），超时为 0。
- 如果没有活动的 handles 或请求，超时为 0。
- 如果有任何活动的 idle handles，超时为 0。
- 如果有任何待关闭的 handles，超时为 0。
- 如果以上情况都不符合，则取最近的定时器的超时，如果没有活动的定时器，则为无限大。
循环阻塞 I/O。此时，循环将阻塞 I/O，持续时间为上一步计算的时间。所有监视给定文件描述符的读或写操作的 I/O 相关 handles 在此时调用其回调函数。
调用 check handle 回调。Check handles 在循环阻塞 I/O 后立即调用其回调函数。Check handles 本质上是 prepare handles 的对应物。
调用关闭回调。如果通过调用 uv_close() 关闭了一个 handle，它将调用关闭回调。
更新循环的“现在”概念。
运行到期的定时器。请注意，“现在”不会在下一个循环迭代之前再次更新。因此，如果在处理其他定时器时有一个定时器到期，它将在下一个事件循环迭代之前不会运行。
迭代结束。如果循环是用 UV_RUN_NOWAIT 或 UV_RUN_ONCE 模式运行的，迭代结束并且 uv_run() 将返回。如果循环是用 UV_RUN_DEFAULT 运行的，并且仍然活跃，则它将从头开始继续，否则它也将结束。

重要提示

libuv 使用线程池使异步文件 I/O 操作成为可能，但网络 I/O 始终在单个线程中执行，即每个循环的线程。

注意

尽管轮询机制不同，libuv 使得在 Unix 系统和 Windows 上的执行模型保持一致。

文件 I/O

与网络 I/O 不同，libuv 没有可以依赖的平台特定文件 I/O 原语，因此当前的方法是在线程池中运行阻塞的文件 I/O 操作。

有关跨平台文件 I/O 详细解释，请查看这篇文章。

libuv 目前使用全局线程池，所有循环都可以在此池中排队工作。目前在此池中运行 3 种类型的操作：

文件系统操作

DNS 函数（getaddrinfo 和 getnameinfo）

用户指定的代码通过 uv_queue_work() 运行

补充说明：
上面提到的文章主要说明为何文件操作不使用操作系统异步IO（如 AIO）而是使用线程池。不过新版本 libuv 也开始使用 io_uring 了。
从 libuv v1.45.0 开始，Linux上的一些文件操作在可能的情况下将转移到 io_uring。除了吞吐量有时会显著增加外，观察到的行为没有变化。当必要的内核特性不可用或不合适时，Libuv 会回退到使用其线程池。

←Back to home

This work is licensed under CC BY-NC-SA 4.0