覺得此文還不錯，收藏以備日後學習。
請教大家乙個關於epollet和epolllt的問題
今天在檢視epollet和epolllt的細節的時候，發現一篇文章。 但不知文中說的是否有道理，望各位大大給個明確的答覆。
遊戲伺服器，我們用的是et方式。
平時大家使用 epoll 時都知道其事件觸發模式有預設的 level-trigger 模式和通過 epollet 啟用的 edge-trigger 模式兩種。從 epoll 發展歷史來看，它剛誕生時只有 edge-trigger 模式，後來因容易產生 race-cond 且不易被開發者理解，又增加了 level-trigger 模式並作為預設處理方式。
二者的差異在於 level-trigger 模式下只要某個 fd 處於 readable/writable 狀態，無論什麼時候進行 epoll_wait 都會返回該 fd；而 edge-trigger 模式下只有某個 fd 從 unreadable 變為 readable 或從 unwritable 變為 writable 時，epoll_wait 才會返回該 fd。
通常的誤區是：level-trigger 模式在 epoll 池中存在大量 fd 時效率要顯著低於 edge-trigger 模式。
但從 kernel **來看，edge-trigger/level-trigger 模式的處理邏輯幾乎完全相同，差別僅在於 level-trigger 模式在 event 發生時不會將其從 ready list 中移除，略為增大了 event 處理過程中 kernel space 中記錄資料的大小。
歡迎就此話題進行深入調研、討論！
參考資料：
• linux kernel source：fs/eventpoll.c
• 「comparing and evaluating epoll, select, and poll event
mechanisms」：
• 「edge-triggered inte***ces are too difficult?」：
by qingwu
編輯收藏
引用 所屬分類: programming
#re: 請教大家乙個關於epollet和epolllt的問題
2013-02-26 16:14
peakflys
其實這個問題我之前在一篇blog裡已經討論過(
我現在的結論是：et模式在網路層方面的效率確實比lt要高。
主要表現在：
1、網路io比較小時，send buffer表現為一直可寫，如果網路主迴圈沒有延時操作的話，epoll_wait每次呼叫都會馬上有事件返回，導致不必要的cpu空耗。
2、在網路io比較大，尤其是連線數比較多的時候，每次epoll_wait呼叫時lt模式肯定比et模式多，因為之後需要對ready list 進行遍歷處理，如果處理邏輯比較複雜，或者之前反饋的事件數lt比et多很多的話，這時候效率差異就比較明顯了。
還是那句話，et模式在網路主迴圈處理的效率肯定比lt模式要高，至於高多少，視具體應用和具體實現。當然et模式的代價就是增加了網路層的邏輯處理複雜度，必須保證時刻知道fd當前的狀態。
原文出處：
關於乙個加法優化的乙個地方
include include include base.h int main int argc,char argv,char envp 下面是彙編 01291000 55 push ebp 01291001 8bec mov ebp,esp 01291003 56 push esi 0129100...
乙個關於wcscpy和wcscpy s的問題
wcscpy 即為strcpy 的寬字元版本 unicode 與 t類似的，visual c 提供了類似的同名函式 ifdef unicode define tcscpy wcscpy else define tcscpy strcpy endif wcscpy s的作用和前面一樣，不過是ms搞出來...
乙個關於 Autowired和AOP的問題
當我需要做乙個aop日誌時，出現的這個問題。首先，專案是spring cloud 的分布式架構，當我通過aop切api介面獲取到相關資訊後，就需要呼叫db服務的儲存日誌的介面，結果然後就報錯了，說這個fegin介面not found。給我氣得，這東西咋可能沒有注入。找了很多網路上關於aop 無法注入...