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

EPOLL事件有兩種模型：
Edge Triggered (ET)
Level Triggered (LT)

假如有這樣一個例子：
1. 我們已經(jīng)把一個用來從管道中讀取數(shù)據(jù)的文件句柄(RFD)添加到epoll描述符
2. 這個時候從管道的另一端被寫入了2KB的數(shù)據(jù)
3. 調(diào)用epoll_wait(2)，并且它會返回RFD，說明它已經(jīng)準備好讀取操作
4. 然后我們讀取了1KB的數(shù)據(jù)
5. 調(diào)用epoll_wait(2)......

Edge Triggered 工作模式：
如果我們在第1步將RFD添加到epoll描述符的時候使用了EPOLLET標志，那么在第5步調(diào)用epoll_wait(2)之后將有可能會掛起，因為剩余的數(shù)據(jù)還存在于文件的輸入緩沖區(qū)內(nèi)，而且數(shù)據(jù)發(fā)出端還在等待一個針對已經(jīng)發(fā)出數(shù)據(jù)的反饋信息。只有在監(jiān)視的文件句柄上發(fā)生了某個事件的時候 ET 工作模式才會匯報事件。因此在第5步的時候，調(diào)用者可能會放棄等待仍在存在于文件輸入緩沖區(qū)內(nèi)的剩余數(shù)據(jù)。在上面的例子中，會有一個事件產(chǎn)生在RFD句柄上，因為在第2步執(zhí)行了一個寫操作，然后，事件將會在第3步被銷毀。因為第4步的讀取操作沒有讀空文件輸入緩沖區(qū)內(nèi)的數(shù)據(jù)，因此我們在第5步調(diào)用 epoll_wait(2)完成后，是否掛起是不確定的。epoll工作在ET模式的時候，必須使用非阻塞套接口，以避免由于一個文件句柄的阻塞讀/阻塞寫操作把處理多個文件描述符的任務(wù)餓死。最好以下面的方式調(diào)用ET模式的epoll接口，在后面會介紹避免可能的缺陷。
?? i??? 基于非阻塞文件句柄
?? ii?? 只有當read(2)或者write(2)返回EAGAIN時才需要掛起，等待。但這并不是說每次read()時都需要循環(huán)讀，直到讀到產(chǎn)生一個EAGAIN才認為此次事件處理完成，當read()返回的讀到的數(shù)據(jù)長度小于請求的數(shù)據(jù)長度時，就可以確定此時緩沖中已沒有數(shù)據(jù)了，也就可以認為此事讀事件已處理完成。

Level Triggered 工作模式
相反的，以LT方式調(diào)用epoll接口的時候，它就相當于一個速度比較快的poll(2)，并且無論后面的數(shù)據(jù)是否被使用，因此他們具有同樣的職能。因為即使使用ET模式的epoll，在收到多個chunk的數(shù)據(jù)的時候仍然會產(chǎn)生多個事件。調(diào)用者可以設(shè)定EPOLLONESHOT標志，在 epoll_wait(2)收到事件后epoll會與事件關(guān)聯(lián)的文件句柄從epoll描述符中禁止掉。因此當EPOLLONESHOT設(shè)定后，使用帶有 EPOLL_CTL_MOD標志的epoll_ctl(2)處理文件句柄就成為調(diào)用者必須作的事情。


然后詳細解釋ET, LT:

LT(level triggered)是缺省的工作方式，并且同時支持block和no-block socket.在這種做法中，內(nèi)核告訴你一個文件描述符是否就緒了，然后你可以對這個就緒的fd進行IO操作。如果你不作任何操作，內(nèi)核還是會繼續(xù)通知你的，所以，這種模式編程出錯誤可能性要小一點。傳統(tǒng)的select/poll都是這種模型的代表．

ET(edge-triggered)是高速工作方式，只支持no-block socket。在這種模式下，當描述符從未就緒變?yōu)榫途w時，內(nèi)核通過epoll告訴你。然后它會假設(shè)你知道文件描述符已經(jīng)就緒，并且不會再為那個文件描述符發(fā)送更多的就緒通知，直到你做了某些操作導(dǎo)致那個文件描述符不再為就緒狀態(tài)了(比如，你在發(fā)送，接收或者接收請求，或者發(fā)送接收的數(shù)據(jù)少于一定量時導(dǎo)致了一個EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個fd作IO操作(從而導(dǎo)致它再次變成未就緒)，內(nèi)核不會發(fā)送更多的通知(only once),不過在TCP協(xié)議中，ET模式的加速效用仍需要更多的benchmark確認（這句話不理解）。

在許多測試中我們會看到如果沒有大量的idle -connection或者dead-connection，epoll的效率并不會比select/poll高很多，但是當我們遇到大量的idle- connection(例如WAN環(huán)境中存在大量的慢速連接)，就會發(fā)現(xiàn)epoll的效率大大高于select/poll。（未測試）



另外，當使用epoll的ET模型來工作時，當產(chǎn)生了一個EPOLLIN事件后，
讀數(shù)據(jù)的時候需要考慮的是當recv()返回的大小如果等于請求的大小，那么很有可能是緩沖區(qū)還有數(shù)據(jù)未讀完，也意味著該次事件還沒有處理完，所以還需要再次讀取：
while(rs)
{
? buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
? if(buflen < 0)
? {
??? // 由于是非阻塞的模式,所以當errno為EAGAIN時,表示當前緩沖區(qū)已無數(shù)據(jù)可讀
??? // 在這里就當作是該次事件已處理處.
??? if(errno == EAGAIN)
???? break;
??? else
???? return;
?? }
?? else if(buflen == 0)
?? {
???? // 這里表示對端的socket已正常關(guān)閉.
?? }
?? if(buflen == sizeof(buf)
???? rs = 1;?? // 需要再次讀取
?? else
???? rs = 0;
}


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

ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)
{
? ssize_t tmp;
? size_t total = buflen;
? const char *p = buffer;

? while(1)
? {
??? tmp = send(sockfd, p, total, 0);
??? if(tmp < 0)
??? {
????? // 當send收到信號時,可以繼續(xù)寫,但這里返回-1.
????? if(errno == EINTR)
??????? return -1;

????? // 當socket是非阻塞時,如返回此錯誤,表示寫緩沖隊列已滿,
????? // 在這里做延時后再重試.
????? if(errno == EAGAIN)
????? {
??????? usleep(1000);
??????? continue;
????? }

????? return -1;
??? }

??? if((size_t)tmp == total)
????? return buflen;

??? total -= tmp;
??? p += tmp;
? }

? return tmp;
}

總結(jié)

以上是生活随笔為你收集整理的epoll的ET和LT模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。