查閱了一些資料，才知道常用的事件處理庫很多都選擇了 lt 模式，包括大家熟知的libevent和boost::asio等，為什麼選擇lt呢？那就不得不從et的弊端的弊端說起。
et模式下，當有事件發生時，系統只會通知你一次，也就是呼叫epoll_wait 返回fd後，不管事件你處理與否，或者處理完全與否，再呼叫epoll_wait 時，都不會再返回該fd，這樣programmer要自己保證在事件發生時及時有效的處理完。比如此時fd發生了epollin事件，在呼叫epoll_wait 後發現此事件，programmer要保證在本次輪詢中對此fd進行了讀操作，並且還要迴圈呼叫recv操作，一直讀到recv的返回值小於請求值，或者遇到eagain錯誤，不然下次輪詢時，如果此fd沒有再次觸發事件，你就沒有機會知道這個fd需要你的處理。這樣無形中就增加了programmer的負擔和出錯的機會。
et模式的短處正是lt模式的長處，無論此fd是否有事件發生，或者有事件未處理完，每次epoll_wait 時總會得到此fd供你處理。顯而易見，os在lt模式下維護的 ready list 的大小肯定比et模式下長，而且你自己輪詢所有的fd時也要比et下要多，這種消耗和et模式下迴圈呼叫處理函式(如recv和send等)，還要邏輯處理是否處理完畢，理論上應該是lt更大一些，不過個人感覺應該差別不會太大。但是lt模式下帶來的邏輯處理的方便性和不易出錯性，讓我們有理由把它作為首選。我想這可能也是為什麼epoll後來在et的基礎上又增加了lt，並且將其作為預設模式的原因吧。
peakflys 上述觀點，歡迎 志同道合或志同道不合的朋友拍磚。
**：
epoll的ET模式和LT模式
lt模式 epoll預設的工作模式。如果描述符上的事件就緒，但是它的資料沒有處理完，或者沒有處理 epoll下次會提醒他，讓他處理。換個說法，如果fd對應的緩衝區有資料，就會呼叫一次epoll wait，直到資料全部被處理完。et模式 如果描述符上的事件就緒，但是它的資料沒有處理完，或者沒有處理。e...
epoll的ET和LT模式
從man手冊中，得到et和lt的具體描述如下 epoll事件有兩種模型 edge triggered et level triggered lt 假如有這樣乙個例子 1.我們已經把乙個用來從管道中讀取資料的檔案控制代碼 rfd 新增到epoll描述符 2.這個時候從管道的另一端被寫入了2kb的資料 ...
epoll的ET模式與LT模式
1 include wrap.h 2 include 3 include 4 define max event num 1024 5 define buff size 1067 void delfd int epollfd int fd 815 void addfd int epollfd int ...