使用帶很少量文件描述符的epoll有什麼好處嗎？

Question

下面的單線程UDP客戶端應用程序看到使用epoll而不是簡單地調用非阻塞套接字上的recvfrom/sendto會帶來性能好處嗎？

讓我來解釋客戶端。

我正在編寫單線程UDP客戶端（自定義協議），它使用非阻塞I/O發送和接收數據，我的同事建議我使用epoll。 客戶端發送和接收多個信息包，這些信息包都與一個唯一的會話ID相關聯，並且可以同時運行多個會話。

如果我使用epoll，epoll_wait可能會等待的文件描述符的數量可能有限。每個文件描述符都將與一個會話相關聯。所以這是最多10 - 20次會議，這個數字將被強制執行。

每個會話都有它自己的狀態機。從一個單獨的線程中，我需要合理頻繁地運行每個狀態機，並輪詢相關的套接字。

就我而言，我不得不使用epoll_wait爲零的超時或一些非常小的值，以便我可以給CPU時間來運行狀態機爲每個會話。 如果有會話的數據，那麼它需要被定向到關聯的狀態機。

但是，用這麼少的文件描述符我看不出這個設計有什麼好處。

我看到它的方式是我有兩個設計選項： 1.在我使用epoll的主循環中，我可以使用epoll_wait輪詢描述符，使用一個小超時或無超時。

在這一點上它是如何處理的數據是在那裏我變得有點卡住......任我讀它的時候了，然後把它扔進了每個狀態機隊列拿起時，它的運行，或者我設置狀態機上的一個標誌，告訴它數據正在等待，狀態機運行時它會通過調用recvfrom來檢測它。或者，我讀取數據並立即處理，併爲其運行狀態機。

或... 2，從主循環中運行每個狀態機並調用recvfrom。如果我得到一些數據，處理它。如果我不這樣做，那麼不管狀態機需要什麼。沒有數據時是否有巨大的開銷調用recvfrom？

隨着走epoll路線我編碼在一些額外的複雜性。如果在我的情況下有更強的可能性，那麼我會開始做。但是，如果第二種方法非常簡單，那麼我就不會使用epoll。

有什麼想法？

Answer 1

沒有，事實上性能將使用epoll如果添加和從一組調查移除文件描述符更糟糕是什麼，但一個極其罕見的事件。通過poll，一個系統調用執行整個操作。使用epoll，您需要多個系統調用來修改該集合，然後等待它。

除非您正在編寫旨在擴展到數十，數百或數千個長期持久連接的服務器，否則epoll不僅是不成熟的優化，而且實際上是一種悲觀化。它也完全不標準和不可移植。