redis: event loop

yw6866

redis用一个event loop作为事件分发器(dispatcher)，他的作用就是“挡在前面”，对应外界的IO。涉及文件:　　ae.h, ae.c, ae_epoll.c, ae_select.c, ae_kqueue.c
版本: 2.4.4ae.c中定义了event loop的主体，剩余三个文件(ae_epoll.c, ae_select.c, ae_kqueue.c)分别是三种底层api的封装。对event loop来说，它们通过一组预定义的接口来通信，epoll、select、kqueue是底层的三种具体实现。event loop处理两种类型的event：

• 文件IO(Socket是一种文件IO)事件
  
• 定时器事件
  

• 文件事件（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。主体框架的步骤：

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

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