Tornado 源码阅读笔记（二）

主要看一下 Kqueue 的原理

翻译自 (Kqueue: A generic and scalable event notification facility) 这篇论文

 

 

概要

在 Unix 平台下，当 socket 或者其他的 descriptor 状态发生变化时，相关的应用应该收到通知。过去是通过系统调用 select() 和 poll() 来实现的。

 

但是，事实证明，在大量 descriptor 的情况下，这两种机制性能低下。

除了性能问题，这两种实现在功能上也不能满足需求。例如，不能处理以下事件：signals, file system changes, AIO completions.

 

于是，Kqueue 应运而生。它允许应用程序响应一系列不同的事件种类，并且更加高效。同时，可以做到在不修改应用程序接口的情况下，响应未来可能出现的新的事件种类。

 

 

1 介绍

应用程序通常是 event driven，也就是来一个事件，处理一个事件。所以，通常应用程序的性能取决于检测和响应这些事件的效率。

 

FreeBSD 提供了两个系统调用来监测 file descriptor 的动态，即 poll() and select()。但是，在大量 file descriptor 需要监控的情况下，这两个家伙都不够给力。有互联网服务端开发经验的兄弟都知道，服务器通常需要同时处理几千个请求，即监控几千个 descriptor。所以，这两个家伙便成了性能瓶颈。

 

应用程序需要监测的事件，并不局限于 activity on an open file descriptor. 应用程序同样需要能够监测到 when an asynchronous I/O (AIO) request completes, when a signal is delivered to the application, when a file in the filesystem changes in some fashion, or when a process exits. 而 poll() select() 无法监测这些事件，于是我们就需要大量的额外代码来处理这些问题，增加了代码的复杂度。

 

Kqueue 则允许应用程序 register its interest in a specific event, 并且稍候高效地收集 the notification of the event. 同时，除了上面列出的事件类型，还能够监控未来可能出现的新的事件类型（在不修改现有 API 的情况下）。

 

 

2 问题

poll() select() 的缺陷在于，对于每次调用，都需要传入完整的 descriptor 列表。这将迫使系统执行两次内存拷贝 across the uesr/kernel boundary, 占用大量内存。对于需要监控几千个 descriptor 的情况，实践证明，通常只有 a few hundred actually have any activity, 造成 95％ 的拷贝操作都是不必要的。

 

监控的结果返回之后，应用程序需要遍历整个 descriptor 列表， 以寻找那些被 kernel 标记为 having activity 的。既然 kernel 已经知道 which descriptor were active，这就意味着做了重复的工作。更高效的方法是，kernel 只返回 a list of descriptor that it knows is active. 遍历列表的复杂度是 O(N), 当 N 变得非常大时，性能就会很差。

 

在 kernel 内部，情况也非常糟糕。kernel 必须分配空间来存放 descriptor 列表；对于较大的列表，往往是通过 malloc() 来实现，并且在返回结果之前，这部分空间必须释放掉。

 

// ===== 原文第二部分的余下论述，我实在不能理解，需要再查一下其他的资料 =====