redis: event loop

redis用一个event loop作为事件分发器(dispatcher)，他的作用就是“挡在前面”，对应外界的IO。 涉及文件:

ae.h, ae.c, ae_epoll.c, ae_select.c, ae_kqueue.c

版本: 2.4.4 ae.c中定义了event loop的主体，剩余三个文件(ae_epoll.c, ae_select.c, ae_kqueue.c)分别是三种底层api的封装。对event loop来说，它们通过一组预定义的接口来通信，epoll、select、kqueue是底层的三种具体实现。 event loop处理两种类型的event：

1. 文件IO(Socket是一种文件IO)事件
2. 定时器事件

• 文件事件（File Event）

对于文件IO，每个事件都用一个文件句柄来表示，再加上对应的读写性质描述和处理函数。但是，这里有个繁琐的过程：必须在event loop登记这些详细的信息（读写描述以及处理函数），而且，为了底层api能够正常运行，这些信息也必须同时送入到底层的api中（比如epoll）。所以，每次注册或者删除一个事件，都要把注册信息走两遍（一遍记录在event loop；一遍记录在底层api），这实在是一个无奈。 在event loop中，准备了两个大的表格来登记文件事件：events和fired，就是两个数组；另外有一个maxfd，记录了当前最大的文件句柄号（这个设计完全依赖于文件系统）。  

• 定时器事件（Timer Event）

定时器事件用一个队列组织起来，每个事件都分配一个唯一的ID。 作者写了两个很脏的函数： asSearchNearestTimer，找出最近一个需要fire的timer，用了一个简单的O(N)事件的暴力查找； processTimeEvents，处理所有超时的timer事件，也是暴力方法.  

• 处理框架(aeProcessEventLoop) 

定时器事件用一个队列组织起来，每个事件都分配一个唯一的ID。主体框架的步骤：

1. 找出当前event loop中最近一个需要触发的timer event，把时间记录下来，设为 t
2. 调用底层的api，进行poll操作，进入睡眠（等待IO），并且把time out设定为t
3. 如果有IO事件被触发，就调用对应的处理函数。当然，这里有个内部数据结构，把事件传递出来。
4. 调用processTimeEvents，处理定时器事件

  总体感觉，这个event loop有点脏，不够优雅。但是，真实世界也许就是这样的。当年的MFC，那个event loop也很脏~~