epoll機制和簡述

在linux的網絡編程中，很長的時間都在使用select來作事件觸發。在linux新的內核中，有了一種替換它的機制，就是epoll。相比於select，epoll最大的好處在於它不會隨着監聽fd數目的增加而下降效率。由於在內核中的select實現中，它是採用輪詢來處理的，輪詢的fd數目越多，天然耗時越多。而且，linux/posix_types.h頭文件有這樣的聲明：

#define__FD_SETSIZE   1024

         表示select最多同時監聽1024個fd，固然，能夠經過修改頭文件再重編譯內核來擴大這個數目，但這彷佛並不治本。

epoll的接口很是簡單，一共就三個函數：
1.建立epoll句柄
   int epfd = epoll_create(intsize);                                                                   

       建立一個epoll的句柄，size用來告訴內核這個監聽的數目一共有多大。這個參數不一樣於select()中的第一個參數，給出最大監聽的fd+1的值。須要注意的是，當建立好epoll句柄後，它就是會佔用一個fd值，在linux下若是查看/proc/進程id/fd/，是可以看到這個fd的，因此在使用完epoll後，必須調用close()關閉，不然可能致使fd被耗盡。
函數聲明：int epoll_create(int size)
該 函數生成一個epoll專用的文件描述符。它實際上是在內核申請一空間，用來存放你想關注的socket fd上是否發生以及發生了什麼事件。size就是你在這個epoll fd上能關注的最大socket fd數。隨你定好了。只要你有空間。可參見上面與select之不一樣
2.將被監聽的描述符添加到epoll句柄或從epool句柄中刪除或者對監聽事件進行修改。

函數聲明：int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)
該函數用於控制某個epoll文件描述符上的事件，能夠註冊事件，修改事件，刪除事件。
參數：
epfd：由 epoll_create 生成的epoll專用的文件描述符；
op：要進行的操做例如註冊事件，可能的取值EPOLL_CTL_ADD 註冊、EPOLL_CTL_MOD 修 改、EPOLL_CTL_DEL 刪除

fd：關聯的文件描述符；
event：指向epoll_event的指針；
若是調用成功返回0,不成功返回-1

   int epoll_ctl(int epfd, int op, int fd, struct epoll_event*event); 

   epoll的事件註冊函數，它不一樣與select()是在監聽事件時告訴內核要監聽什麼類型的事件，而是在這裏先註冊要監聽的事件類型。

           第一個參數是epoll_create()的返回值，
           第二個參數表示動做，用三個宏來表示：
           EPOLL_CTL_ADD：       註冊新的fd到epfd中；
          EPOLL_CTL_MOD：      修改已經註冊的fd的監聽事件；
           EPOLL_CTL_DEL：        從epfd中刪除一個fd；
         第三個參數是須要監聽的fd，
          第四個參數是告訴內核須要監聽什麼事件，structepoll_event結構以下：

typedef union epoll_data {
void *ptr;
int fd;
__uint32_t u32;
__uint64_t u64;
} epoll_data_t;

struct epoll_event {
__uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};

        events能夠是如下幾個宏的集合：
         EPOLLIN：            觸發該事件，表示對應的文件描述符上有可讀數據。(包括對端SOCKET正常關閉)；
         EPOLLOUT：         觸發該事件，表示對應的文件描述符上能夠寫數據；
        EPOLLPRI：           表示對應的文件描述符有緊急的數據可讀（這裏應該表示有帶外數據到來）；
        EPOLLERR：        表示對應的文件描述符發生錯誤；
         EPOLLHUP：        表示對應的文件描述符被掛斷；
        EPOLLET：           將EPOLL設爲邊緣觸發(Edge Triggered)模式，這是相對於水平觸發(Level Triggered)來講的。
        EPOLLONESHOT：  只監聽一次事件，當監聽完此次事件以後，若是還須要繼續監聽這個socket的話，須要再次把這個socket加入到EPOLL隊列裏。
如：
struct epoll_event ev;
//設置與要處理的事件相關的文件描述符
ev.data.fd=listenfd;
//設置要處理的事件類型
ev.events=EPOLLIN|EPOLLET;
//註冊epoll事件
epoll_ctl(epfd,EPOLL_CTL_ADD,listenfd,&ev);
3.等待事件觸發，當超過timeout尚未事件觸發時，就超時。
   int epoll_wait(int epfd, struct epoll_event * events, intmaxevents, int timeout);
    等待事件的產生，相似於select()調用。參數events用來從內核獲得事件的集合，maxevents告以內核這個events有多大(數組成員的個數)，這個maxevents的值不能大於建立epoll_create()時的size，參數timeout是超時時間（毫秒，0會當即返回，-1將不肯定，也有說法說是永久阻塞）。
    該函數返回須要處理的事件數目，如返回0表示已超時。
    返回的事件集合在events數組中，數組中實際存放的成員個數是函數的返回值。返回0表示已經超時。
函數聲明:int epoll_wait(int epfd,struct epoll_event * events,int maxevents,int timeout)
該函數用於輪詢I/O事件的發生；
參數：
epfd:由epoll_create 生成的epoll專用的文件描述符；
epoll_event:用於回傳代處理事件的數組；
maxevents:每次能處理的事件數；
timeout:等待I/O事件發生的超時值(單位我也不太清楚)；-1至關於阻塞，0至關於非阻塞。通常用-1便可
返回發生事件數。
epoll_wait運行的原理是
等侍註冊在epfd上的socket fd的事件的發生，若是發生則將發生的sokct fd和事件類型放入到events數組中。
並 且將註冊在epfd上的socket fd的事件類型給清空，因此若是下一個循環你還要關注這個socket fd的話，則須要用epoll_ctl(epfd,EPOLL_CTL_MOD,listenfd,&ev)來從新設置socket fd的事件類型。這時不用EPOLL_CTL_ADD,由於socket fd並未清空，只是事件類型清空。這一步很是重要。
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

從man手冊中，獲得ET和LT的具體描述以下
EPOLL事件有兩種模型：
Edge Triggered(ET)       //高速工做方式，錯誤率比較大，只支持no_block socket (非阻塞socket)
LevelTriggered(LT)       //缺省工做方式，即默認的工做方式,支持blocksocket和no_blocksocket，錯誤率比較小。

假若有這樣一個例子：(LT方式，即默認方式下，內核會繼續通知，能夠讀數據，ET方式，內核不會再通知，能夠讀數據)
1.咱們已經把一個用來從管道中讀取數據的文件句柄(RFD)添加到epoll描述符
2. 這個時候從管道的另外一端被寫入了2KB的數據
3. 調用epoll_wait(2)，而且它會返回RFD，說明它已經準備好讀取操做
4. 而後咱們讀取了1KB的數據
5. 調用epoll_wait(2)......

Edge Triggered工做模式：
        若是咱們在第1步將RFD添加到epoll描述符的時候使用了EPOLLET標誌，那麼在第5步調用epoll_wait(2)以後將有可能會掛起，由於剩餘的數據還存在於文件的輸入緩衝區內，並且數據發出端還在等待一個針對已經發出數據的反饋信息。只有在監視的文件句柄上發生了某個事件的時候ET工做模式纔會彙報事件。所以在第5步的時候，調用者可能會放棄等待仍在存在於文件輸入緩衝區內的剩餘數據。在上面的例子中，會有一個事件產生在RFD句柄上，由於在第2步執行了一個寫操做，而後，事件將會在第3步被銷燬。由於第4步的讀取操做沒有讀空文件輸入緩衝區內的數據，所以咱們在第5步調用epoll_wait(2)完成後，是否掛起是不肯定的。epoll工做在ET模式的時候，必須使用非阻塞套接口，以免因爲一個文件句柄的阻塞讀/阻塞寫操做把處理多個文件描述符的任務餓死。最好如下面的方式調用ET模式的epoll接口，在後面會介紹避免可能的缺陷。(LT方式能夠解決這種缺陷)
  i   基於非阻塞文件句柄
  ii  只有當read(2)或者write(2)返回EAGAIN時(認爲讀完)才須要掛起，等待。但這並非說每次read()時都須要循環讀，直到讀到產生一個EAGAIN才認爲這次事件處理完成，當read()返回的讀到的數據長度小於請求的數據長度時(即小於sizeof(buf))，就能夠肯定此時緩衝中已沒有數據了，也就能夠認爲此事讀事件已處理完成。

Level Triggered工做模式         (默認的工做方式)
     相反的，以LT方式調用epoll接口的時候，它就至關於一個速度比較快的poll(2)，而且不管後面的數據是否被使用，所以他們具備一樣的職能。由於即便使用ET模式的epoll，在收到多個chunk的數據的時候仍然會產生多個事件。調用者能夠設定EPOLLONESHOT標誌，在epoll_wait(2)收到事件後epoll會與事件關聯的文件句柄從epoll描述符中禁止掉。所以當EPOLLONESHOT設定後，使用帶有EPOLL_CTL_MOD標誌的epoll_ctl(2)處理文件句柄就成爲調用者必須做的事情。

而後詳細解釋ET, LT:
         //沒有對就緒的fd進行IO操做，內核會不斷的通知。
         LT(leveltriggered)是缺省的工做方式，而且同時支持block和no-blocksocket。在這種作法中，內核告訴你一個文件描述符是否就緒了，而後你能夠對這個就緒的fd進行IO操做。若是你不做任何操做，內核仍是會繼續通知你的，因此，這種模式編程出錯誤可能性要小一點。傳統的select/poll都是這種模型的表明。
          //沒有對就緒的fd進行IO操做，內核不會再進行通知。
         ET(edge-triggered)是高速工做方式，只支持no-blocksocket。在這種模式下，當描述符從未就緒變爲就緒時，內核經過epoll告訴你。而後它會假設你知道文件描述符已經就緒，而且不會再爲那個文件描述符發送更多的就緒通知，直到你作了某些操做致使那個文件描述符再也不爲就緒狀態了(好比，你在發送，接收或者接收請求，或者發送接收的數據少於必定量時致使了一個EWOULDBLOCK錯誤）。可是請注意，若是一直不對這個fd做IO操做(從而致使它再次變成未就緒)，內核不會發送更多的通知(only once),不過在TCP協議中，ET模式的加速效用仍須要更多的benchmark確認（這句話不理解）。

另外，當使用epoll的ET模型(epoll的非默認工做方式)來工做時，當產生了一個EPOLLIN事件後，
        讀數據的時候須要考慮的是當recv()返回的大小若是等於要求的大小，即sizeof(buf)，那麼頗有多是緩衝區還有數據未讀完，也意味着該次事件尚未處理完，因此還須要再次讀取：
while(rs)           //ET模型
{
          buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
          if(buflen < 0)
          {
                        //因爲是非阻塞的模式,因此當errno爲EAGAIN時,表示當前緩衝區已無數據可讀
                        // 在這裏就看成是該次事件已處理處.
                         if(errno== EAGAIN || errno == EINT)  //即當buflen<0且errno=EAGAIN時，表示沒有數據了。(讀/寫都是這樣)                               break;                         else