1、監聽事件

設置事件為 EPOLLIN? 或者 EPOLLET | EPOLLIN 。

由于此 socket 只監聽有無連接，談不上寫和其他操作。故只有這兩類。（默認是LT模式，即EPOLLLT |EPOLLIN）。

說明：如果在這個 socket上 也設置 EPOLLOUT 等，也不會出錯，只是這個 socket 不會收到這樣的消息。

2、可讀事件。

EPOLLIN?????

3、可寫事件。

EPOLLOUT

4、客戶端正常關閉，client 端 close() 連接。

server 會報某個 sockfd 可讀，即 EPOLLIN 來臨。然后 recv 一下 ， 如果返回 0 再掉用 epoll_ctl 中的 EPOLL_CTL_DEL，同時 close(sockfd) 。

有些系統會收到一個 EPOLLRDHUP，當然檢測這個是最好不過了。只可惜是有些系統不支持。上面的方法最保險，如果能加上對 EPOLLRDHUP 的處理那就是萬能的了。

最近測試 Ubuntu 18.04 系統，當對端執行 close() 函數時，server 收到了事件 8193，即：EPOLLHUP + EPOLLIN。

5、客戶端異常關閉。

客戶端異常關閉，并不會通知服務器。正常關閉時 read 返回 0 ，異常斷開時檢測不到的。服務器再給一個已經關閉的socket寫數據時，會出錯，這時候，服務器才明白對方可能已經異常斷開了（讀也可以）。

Epoll中就是向已經斷開的 socket 寫或者讀，會發生 EPOLLERR，即表明已經斷開。

6、補充 EPOLLERR

當客戶端的機器在發送“請求”前，就崩潰了（或者網絡斷掉了），則服務器一端是無從知曉的。按照你現在的這個“請求響應方式”，無論是否使用 epoll，都必須要做超時檢查。因此，這個問題與 epoll 無關。EPOLLERR 這種錯誤必須是有動作才能檢測出來。服務器不可能經常的向客戶端寫一個東西，所以不能依照有沒有 EPOLLERR 來判斷客戶端是不是死了。因此，服務器中的超時檢查是很重要的，這也是以前服務器中作死后確認的原因。

！！！服務器 中的超時檢查！！！很重要。

?

（SAW：Game Over！）

總結

以上是生活随笔為你收集整理的OS / Linux / epoll 各种事件解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。