EPOLL反应堆模型

Readctor
    EPOLLET模式+非阻塞+void* ptr
    不但要监听读事件也要监听写事件
    ----while(1)
    ----epoll_wait监听----返回监听的数组----如果lfd满足（则accept()）----cfd满足
    ---read()----小to大----cfd从监听红黑树摘下
    ----把（EPOLLOUT和回调函数）利用epoll_ctl放入红黑树上
    ----再epoll_wait（监听cfd的写事件）如果监听到cfd的写事件之后--write()----cfd从监听红黑树摘下
    ----把（EPOLLIN）利用epoll_ctl放入红黑树上----

    就是监听到了cfd有读事件了，我们就read(),再摘下来，再放上去监听他的写事件，
    如果监听到了cfd有写事件了，我们就write()再摘下来，再放上去监听他的读事件

    为什么要摘下来放上去：因为我们想改变他的监听事件，

    为什么不和原来的一样监听到了就直接read()再写呢：

(1) 如此频繁的增加删除不是浪费CPU资源吗？
答：对于同一个socket而言，完成收发至少占用两个树上的位置。
而交替只需要一个。任何一种设计方式都会有浪费CPU资源的时候，
关键看你浪费得值不值，此处的耗费能否换来更大的收益才是衡量是否浪费的标准。
和第二个问题综合来看，这里不算浪费

(2) 为什么要可读以后设置可写，然后一直交替？
答：服务器的基本工作无非数据的收发，epoll反应堆模型准从TCP模式，一问一答。
服务器收到了数据，再给予回复，是目前绝大多数服务器的情况。
(2-1) 服务器能收到数据并不是一定能写数据
假设一 ：服务器接收到客户端数据，刚好此时客户端的接收滑动窗口满，
我们假设不进行可写事件设置，并且客户端是有意让自己的接收滑动窗口满的情况(黑客)。
那么，当前服务器将随客户端的状态一直阻塞在可写事件，除非你自己在写数据时设置非阻塞+错误处理
假设二 ：客户端在发送完数据后突然由于异常原因停止，这将导致一个FIN发送至服务器，
如果服务器不设置可写事件监听，那么在接收数据后写入数据会引发异常SIGPIPE，最终服务器进程终止。