在linux的網路程式設計中，很長的時間都在使用select來做事件觸發。在linux新的核心中，有了一種替換它的機制，就是epoll。

相比於select，epoll最大的好處在於它不會隨著監聽fd數目的增長而降低效率。因為在核心中的select實現中，它是採用輪詢來處理的，輪詢的fd數目越多，自然耗時越多。並且，在linux/posix_types.h標頭檔案有這樣的宣告：

#define __FD_SETSIZE    1024

表示select最多同時監聽1024個fd，當然，可以通過修改標頭檔案再重編譯核心來擴大這個數目，但這似乎並不治本。

epoll的介面非常簡單，一共就三個函式：

1. int epoll_create(int size);

建立一個epoll的控制代碼，size用來告訴核心這個監聽的數目一共有多大。這個引數不同於select()中的第一個引數，給出最大監聽的fd+1的值。需要注意的是，當建立好epoll控制代碼後，它就是會佔用一個fd值，在linux下如果檢視/proc/程序id/fd/，是能夠看到這個fd的，所以在使用完epoll後，必須呼叫close()關閉，否則可能導致fd被耗盡。

2. 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，

第四個引數是告訴核心需要監聽什麼事，struct epoll_event結構如下：

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佇列裡

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

等待事件的產生，類似於select()呼叫。引數events用來從核心得到事件的集合，maxevents告之核心這個events有多大，這個maxevents的值不能大於建立epoll_create()時的size，引數timeout是超時時間（毫秒，0會立即返回，-1將不確定，也有說法說是永久阻塞）。該函式返回需要處理的事件數目，如返回0表示已超時。

從man手冊中，得到ET和LT的具體描述如下

EPOLL事件有兩種模型：

Edge Triggered (ET)  邊緣觸發只有資料到來，才觸發，不管快取區中是否還有資料。

Level Triggered (LT)  水平觸發只要有資料都會觸發。

假如有這樣一個例子：

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介面，在後面會介紹避免可能的缺陷。

   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操作。如果你不作任何操作，核心還是會繼續通知你的，所以，這種模式程式設計出錯誤可能性要小一點。傳統的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

     return;

   }

   else if(buflen == 0)

   {

     // 這裡表示對端的socket已正常關閉.

   }

   if(buflen == sizeof(buf)

     rs = 1;   // 需要再次讀取

   else

     rs = 0;

}

還有，假如傳送端流量大於接收端的流量(意思是epoll所在的程式讀比轉發的socket要快),由於是非阻塞的socket,那麼send()函式雖然返回,但實際緩衝區的資料並未真正發給接收端,這樣不斷的讀和發，當緩衝區滿後會產生EAGAIN錯誤(參考man send),同時,不理會這次請求傳送的資料.所以,需要封裝socket_send()的函式用來處理這種情況,該函式會盡量將資料寫完再返回，返回-1表示出錯。在socket_send()內部,當寫緩衝已滿(send()返回-1,且errno為EAGAIN),那麼會等待後再重試.這種方式並不很完美,在理論上可能會長時間的阻塞在socket_send()內部,但暫沒有更好的辦法.

大部分伺服器端epoll程式框架：

for( ; ; )
    {
        nfds = epoll_wait(epfd,events,20,500);
        for(i=0;i<nfds;++i)
        {
            if(events[i].data.fd==listenfd) //如果是主socket的事件，則表示有新的連線
            {
                connfd = accept(listenfd,(sockaddr *)&clientaddr, &clilen); //accept這個連線
                ev.data.fd=connfd;
                ev.events=EPOLLIN|EPOLLET;
                epoll_ctl(epfd,EPOLL_CTL_ADD,connfd,&ev); //將新的fd新增到epoll的監聽佇列中
            }
            else if( events[i].events&EPOLLIN ) //接收到資料，讀socket
            {

            if ( (sockfd = events[i].data.fd) < 0) continue;
                n = read(sockfd, line, MAXLINE)) < 0    //讀
                ev.data.ptr = md;     //md為自定義型別，新增資料
                ev.events=EPOLLOUT|EPOLLET;
                epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev);//修改識別符號，等待下一個迴圈時傳送資料，非同步處理的精髓
            }
            else if(events[i].events&EPOLLOUT) //有資料待發送，寫socket
            {
                struct myepoll_data* md = (myepoll_data*)events[i].data.ptr;    //取資料
                sockfd = md->fd;
                send( sockfd, md->ptr, strlen((char*)md->ptr), 0 );        //傳送資料
                ev.data.fd=sockfd;
                ev.events=EPOLLIN|EPOLLET;
                epoll_ctl(epfd,EPOLL_CTL_MOD,sockfd,&ev); //修改識別符號，等待下一個迴圈時接收資料
            }
            else
            {
                //其他情況的處理
            }
        }
    }

linux c epoll 執行緒池專案下載地址：https://github.com/MSGF-NGINX/ServerMode.git