翻譯的man epoll的：
在man epoll中的notes說到：
epoll事件分發系統可以運轉在兩種模式下：
edge triggered (et)
level triggered (lt)
接下來說明et, 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時才需要掛起，等待
level triggered 工作模式
相反的，以lt方式呼叫epoll介面的時候，它就相當於乙個速度比較快的poll(2)，並且無論後面的資料是否被使用，因此他們具有同樣的職能。因為即使使用et模式的epoll，在收到多個chunk的資料的時候仍然會產生多個事件。呼叫者可以設定epolloneshot標誌，在 epoll_wait(2)收到事件後epoll會將與事件關聯的檔案控制代碼從epoll描述符中禁止掉。因此當epolloneshot設定後，使用帶有 epoll_ctl_mod標誌的epoll_ctl(2)處理檔案控制代碼就成為呼叫者必須作的事情。
下面兩段是從網上找的epoll的較詳細的解釋：
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。（未測試）
另外，man epoll中說明了recv和send的時候緩衝區空和滿的情況，這個錯誤是eagain，則需要等待一段時間再recv或send.並給了乙個**的例子
man中給出了epoll的用法，example程式如下：
for(;;)
setnonblocking(client);
ev.events = epollin | epollet;
ev.data.fd = client;
if (epoll_ctl(kdpfd, epoll_ctl_add, client, &ev) < 0)
}else
do_use_fd(events[n].data.fd);}}
為了考慮上面提到的資料沒有讀完，或傳送緩衝滿的情況，對epollin事件和epollout事件的處理如下
讀資料的時候需要考慮的是當recv()返回的大小如果等於請求的大小，那麼很有可能是緩衝區還有資料未讀完，也意味著該次事件還沒有處理完，所以還需要再次讀取：
while(rs)
else if(buflen == 0)
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()內部,但暫沒有更好的辦法.
ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)
return -1;
}if((size_t)tmp == total)
return buflen;
total -= tmp;
p += tmp;
}return tmp;
} 另外，epoll_create的引數是該epoll_create描述符所監聽的最大描述符數，epoll_wait的maxevents是 epoll_wait一次返回所帶回的最大的事件數，epoll_wait的timeout是-1時表示等待時間不確定。如果出現連線斷了，或未預見的事件，會導致這個客戶端描述符一直占用，不能被釋放。在一貼中就集中討論這個問題。
epoll用法詳解
epoll i o event notification facility 在linux的網路程式設計中，很長的時間都在使用select來做事件觸發。在linux新的核心中，有了一種替換它的機制，就是epoll。相比於select，epoll最大的好處在於它不會隨著監聽fd數目的增長而降低效率。因為...
poll, select與epoll的用法
多路io復用 就是實現同時監控多個檔案描述符 此類檔案描述符必須為不可操作時會進入堵塞狀態 會堵塞直到有乙個或多個檔案描述符可操作為止,通過返回值找出可操作的檔案描術符 可代替多執行緒工作 linux下共有三個函式可完成此工作 一.poll函式 include int poll struct pol...
epoll的原理和用法
設想乙個場景，有100 萬使用者同時與乙個程序保持著 tcp連線，而每一時刻只有幾十個或幾百個tcp連線是活躍的 接收到tcp 包 也就是說，在每一時刻程序只需要處理這 100萬連線中的一小部分連線，那麼，如何才能高效的處理這種場景那，程序是否在每次詢問作業系統收集有事件發生的tcp 連線時，把這 ...