epoll模型兩種工作模式的思考

epoll模型有兩種工作模式，et和lt,兩種模式下都有一些細節值得注意，以下是一些思考:

一、et模式下

q1: 呼叫accept時，到底tcp完成佇列裡有多少個已經建立好的連線?

這裡又得分情況來說:

解決方法: 採用非阻塞的accept，在accept返回後處理econnaborted、eproto、eintr錯誤。

解決辦法: 1)：將該套介面設定為非阻塞模式，然後將accept用while迴圈包住，處理完tcp完成佇列中的所有連線再跳出迴圈。2): 將accept放入乙個單獨的執行緒中，這樣還可以採用阻塞模式。

q2: read函式應當如何處理?

read函式有可能不能夠一次將核心緩衝的資料讀完，由於採用的et模式，epoll_wait不會因為核心緩衝區還有資料而繼續返回。這就會導致核心資料不能及時、完全地讀到服務程式。

解決辦法: 將套介面設定為非阻塞，再用while迴圈包住read一直讀到產生eagain錯誤，採用非阻塞套介面的原因在於防止read被阻塞住。網上看見有的朋友說也可以採用阻塞套介面，判斷read的返回值是否小於期望值，小於就證明資料讀完，但是個人認為這裡存在乙個臨界情況，比如核心緩衝有2048位元組，期望讀1024位元組，讀完第二次後read返回的是1024，等於期望值，於是再讀，但此時核心已經沒有資料，於是read被阻塞(自個的思考，不知有務否)。

個人對這個問題不是很清楚，按資料說法是該緩衝區從不可寫變為可寫則返回，那麼該套介面剛建立的時候處於可寫狀態，是否會導致一直返回不了可寫狀態，也就是說第一次永遠返回不了，因為沒有任何呼叫會使該套介面從不可寫變為可寫。

另外，寫的時候還有些什麼要注意的麼？

二、lt模式下

q1: accept函式

accept函式同樣存在連線被夭折的情況，和et模式下類似。但這種模式下不會存在處理不完多個請求的情況。因為只要有連線存在tcp完成佇列中，epoll_wait就會一直返回。

同樣可以避免因為一次讀不完核心緩衝區的資料的情況。

a1: 不將可寫條件加入epoll集中，採用非阻塞i/o,有資料可寫時，直接寫，如果返回是eagain，則將可寫加入epoll集中，寫完後移出。

epoll模型有兩種工作模式

epoll模型有兩種工作模式，et和lt,兩種模式下都有一些細節值得注意，以下是一些思考 一 et模式下 q1 呼叫accept時，到底tcp完成佇列裡有多少個已經建立好的連線?這裡又得分情況來說 沒有連線。這種情況發生在tcp連線被客戶端夭折，即在服務端呼叫accept之前客戶端給出乙個rst。該...

epoll的兩種工作模式LT ET

之前已經介紹過了epoll的工作機制，以及它和select，poll之間的區別，傳送門 接下來我們詳細介紹一下它的兩種工作模式。lt level triggered lt模式，也叫做水平觸發模式。在該模式下，當有事件發生並呼叫epoll wait後，若未及時處理，下一次呼叫epoll wait仍會繼...

EPOLL兩種模式

select epoll 的特點 select 的特點 select 選擇控制代碼的時候，是遍歷所有控制代碼，也就是說控制代碼有事件響應時，select 需要遍歷所有控制代碼才能獲取到哪些控制代碼有事件通知，因此效率是非常低。但是如果連線很少的情況下，select 和epoll的lt 觸發模式相比，...