程式師世界 >> 編程語言 >> C語言 >> C++ >> C++入門知識 >> linux epoll事件模型詳解

linux epoll事件模型詳解

編輯：C++入門知識

，因為它會復用文件描述符集合來傳遞結果而不用迫使開發者每次等待事件之前都必須重新准備要被偵聽的文件描述符集合，另一點原因就是獲取事件的時候，它無須遍歷整個被偵聽的描述符集，只要遍歷那些被內核IO事件異步喚醒而加入Ready隊列的描述符集合就行了。

epoll的接口非常簡單，一共就三個函數：
1. int epoll_create(int size);
創建一個epoll的句柄，size用來告訴內核這個監聽的數目一共有多大。這個參數不同於select()中的第一個參數，給出最大監聽的fd+1的值。需要注意的是，當創建好epoll句柄後，它就是會占用一個fd值，在linux下如果查看/proc/進程id/fd/，是能夠看到這個fd的，所以。

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event* event);
epoll的事件注冊函數，即注冊要監聽的事件類型。
第一個參數是epoll_create()的返回值，
第二個參數表示動作，用三個宏來表示：
EPOLL_CTL_ADD：注冊新的fd到epfd中；
EPOLL_CTL_MOD：修改已經注冊的fd的監聽事件；
EPOLL_CTL_DEL：從epfd中刪除一個fd；
第三個參數是需要監聽的fd，
第四個參數是告訴內核需要監聽什麼事，struct epoll_event結構如下：

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);
等待事件的產生。參數events 用來從內核得到事件的集合，maxevents 告之內核這個events 有多大，這個maxevents 的值不能大於創建epoll_create()時的size，參數timeout是超時時間（毫秒，0會立即返回，-1將不確定，也有說法說是永久阻塞）。，如返回0表示已超時。

4. 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-blocksocket.在這種做法中，內核告訴你一個文件描述符是否就緒了，然後你可以對這個就緒的fd進行IO操作。如果你不作任何操作，內核還是會繼續通知你的，所以，這種模式編程出錯誤可能性要小一點。傳統的select/poll都是這種模型的代表．

ET(edge-triggered)是高速工作方式，。在這種模式下，當描述符從未就緒變為就緒時，內核通過epoll告訴你。然後它會假設你知道文件描述符已經就緒，並且不會再為那個文件描述符發送更多的就緒通知，直到你做了某些操作導致那個文件描述符不再為就緒狀態了(比如，你在發送，接收或者接收請求，或者發送接收的數據少於一定量時導致了一個EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個fd作IO操作(從而導致它再次變成未就緒)，內核不會發送更多的通知(only once),不過在TCP協議中，ET模式的加速效用仍需要更多的benchmark確認（這句話不理解）。
在許多測試中我們會看到如果沒有大量的idle -connection 或者deadconnection，epoll 的效率並不會比select/poll 高很多，但是當我們遇到大量的idleconnection(例如WAN 環境中存在大量的慢速連接)，就會發現epoll 的效率大大高於select/poll。（未測試）
另外，當使用epoll的ET模型來工作時，當產生了一個EPOLLIN事件後，讀數據的時候需要考慮的是當recv()返回的大小如果等於請求的大小，那麼很有可能是緩沖區還有數據未讀完，也意味著該次事件還沒有處理完，所以還需要再次讀取：

= recv(activeevents[i].data.fd, buf, (buf), (buflen < 
    (errno == (buflen == 
(buflen == = ; 
  } =

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

ssize_t socket_send( sockfd,  *=  *p =(= send(sockfd, p, total, (tmp < 
      (errno == -
      (errno == -((size_t)tmp ==-=+=

g++ myepoll.cpp lxx_net.cc -g -o myepoll

<sys/socket.h><sys/epoll.h><netinet/.h><arpa/inet.h><fcntl.h><unistd.h><stdio.h><errno.h><iostream>

  MAX_EPOLL_SIZE 500
 MAX_CLIENT_SIZE 500
 MAX_IP_LEN      16
 MAX_CLIENT_BUFF_LEN 1024
 QUEUE_LEN 500
 BUFF_LEN 1024
 fd_epoll = - fd_listen = -
typedef  fd;                           
   host[MAX_IP_LEN];           
   port;                         
   len;                          
   buff[MAX_CLIENT_BUFF_LEN];   
    status;                     
*ptr_cli =
 epoll_add( fd_epoll,  fd,  epoll_event * (fd_epoll <  || fd <  || ev == - (epoll_ctl(fd_epoll, EPOLL_CTL_ADD, fd, ev) <  -  epoll_del( fd_epoll,  (fd_epoll <  || fd <  - (epoll_ctl(fd_epoll, EPOLL_CTL_DEL, fd, &ev_del) <  - 
 do_read_data( (idx >== ((n = recv(ptr_cli[idx].fd, ptr_cli[idx].buff+pos, MAX_CLIENT_BUFF_LEN-pos, ))) { 
    fprintf(stdout, +,   (n > ) { 
    ptr_cli[idx].len +=  (errno != EAGAIN) {  
    fprintf(stdout, = 
 =  conn_fd = lxx_net_accept(fd_listen, ( sockaddr *)&cliaddr, & (conn_fd >=  (lxx_net_set_socket(conn_fd, ) !=  i =  flag = 
     (i = ; i < MAX_CLIENT_SIZE; i++ (!== == =  (flag) {
== i |  (epoll_add(fd_epoll, conn_fd, &ev) < =  main( argc,  ** port = (argc == = atoi(argv[ ((fd_listen = lxx_net_listen(port, QUEUE_LEN)) <  -= (fd_epoll <  -
  == (epoll_add(fd_epoll, fd_listen, &ev) < = -= - -=  nfds = epoll_wait(fd_epoll, events, MAX_EPOLL_SIZE,  (nfds <  err = (err != ( i = ; i < nfds; i++ (events[i].data.u32 & 
        do_read_data(events[i].data.u32 &  (events[i].data.fd ==