Edge Triggered 工作模式：

如果我们在第 1 步将 RFD 添加到 epoll 描述符的时候使用了 EPOLLET 标志，那么在第 5 步调用 epoll_wait(2)之后将有可能会挂起，因为剩余的数据还存在于文件的输入缓冲区内，而且数据发出端还在等待一个针对已经发出数据的反馈信息。只有在监视的文件句柄上发生了某个事件的时候 ET 工作模式才会汇报事件。因此在第 5 步的时候，调用者可能会放弃等待仍在存在于文件输入缓冲区内的剩余数据。在上面的例子中，会有一个事件产生在 RFD 句柄上，因为在第 2 步执行了一个写操作，然后，事件将会在第 3 步被销毁。因为第 4 步的读取操作没有读空文件输入缓冲区内的数据，因此我们在第 5 步调用 epoll_wait(2) 完成后，是否挂起是不确定的。 epoll 工作在 ET 模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读 / 阻塞写操作把处理多个文件描述符的任务饿死。最好以下面的方式调用 ET 模式的 epoll 接口，在后面会介绍避免可能的缺陷。

   i    基于非阻塞文件句柄

   ii   只有当 read(2) 或者 write(2) 返回 EAGAIN 时才需要挂起，等待。但这并不是说每次 read() 时都需要循环读，直到读到产生一个 EAGAIN 才认为此次事件处理完成，当 read() 返回的读到的数据长度小于请求的数据长度时，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。

Level Triggered 工作模式

相反的，以 LT 方式调用 epoll 接口的时候，它就相当于一个速度比较快的 poll(2) ，并且无论后面的数据是否被使用，因此他们具有同样的职能。因为即使使用 ET 模式的 epoll ，在收到多个 chunk 的数据的时候仍然会产生多个事件。调用者可以设定 EPOLLONESHOT 标志，在 epoll_wait(2) 收到事件后 epoll 会与事件关联的文件句柄从 epoll 描述符中禁止掉。因此当 EPOLLONESHOT 设定后，使用带有 EPOLL_CTL_MOD 标志的 epoll_ctl(2)处理文件句柄就成为调用者必须作的事情。

然后详细解释 ET, LT:

LT(level triggered) 是 缺省 的工作方式 ，并且同时支持 block 和 no-block socket. 在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的 fd 进行 IO 操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程(www.cppentry.com)出错误可能性要小一点。传统的 select/poll 都是这种模型的代表．

ET(edge-triggered) 是高速工作方式 ，只支持 no-block socket 。在这种模式下，当描述符从未就绪变为就绪时，内核通过 epoll 告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了 ( 比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个 EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd 作 IO 操作 ( 从而导致它再次变成未就绪 ) ，内核不会发送更多的通知 (only once), 不过在 TCP 协议中， ET模式的加速效用仍需要更多的 benchmark 确认（这句话不理解）。

在许多测试中我们会看到如果没有大量的 idle -connection 或者 dead-connection ， epoll 的效率并不会比select/poll 高很多，但是当我们遇到大量的 idle- connection( 例如 WAN 环境中存在大量的慢速连接 ) ，就会发现epoll 的效率大大高于 select/poll 。（未测试）

另外，当使用 epoll 的 ET 模型来工作时，当产生了一个 EPOLLIN 事件后，

读数据的时候需要考虑的是当 recv() 返回的大小如果等于请求的大小，那么很有可能是缓冲区还有数据未读完，也意味着该次事件还没有处理完，所以还需要再次读取：

while(rs)

{

  buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);

  if(buflen < 0)

  {

    // 由于是非阻塞的模式 , 所以当 errno 为 EAGAIN 时 , 表示当前缓冲区已无数据可读

    // 在这里就当作是该次事件已处理处 .

    if(errno == EAGAIN)

     break;

    else