Linux服務端編程。關於IO復用，在epoll出現多年的情況下，select和poll還有使用場景嗎？

01-03

Linux服務端編程。關於IO復用，在epoll出現多年的情況下，select和poll還有使用場景嗎？
請不要說可移植性的問題，使用場景就是Linux，一般伺服器的內核也大於等於2.6了吧。
另外介紹一下pselect和ppoll用得多麼？

有的時候select只是用來實現單個文件描述符的超時……這種情況完全沒必要那麼麻煩地使用epoll。

還有貌似文件描述符數量很少的時候，epoll性能反而不如其他那幾個。

管理少量連接（比如fd數 &< 10），poll/select 是比較輕量級的，不需要去創建一個 epoll的 fd。
編寫跨平台代碼，保證代碼任意平台都能用，那麼 cygwin 下只有 poll 給你，win32下對應 select

別腦袋裡面只有 Linux 呀，世界大得很，主流的還有 FreeBSD, Aix, Darwin, Solaris, HP Unix ....

嵌入式編程里，串口啦，攝像頭啦之類的，select更好一些，兼容性更好。

epoll與select/poll性能，CPU/內存開銷對比 -- 簡明現代魔法我是個搬運工。。(/ □ )

在有epoll 後，那些應用場景下還需要select？ - 陳碩的回答

不要問我為什麼會被摺疊，我不知道。

除了樓上討論到的文件描述符數量，還有個需要考慮地方，就是各個描述符的活躍程度。當每個連接都很活躍時，select和epoll的性能並沒有那麼大。我的理解是epoll更適合處理大量連接但是不是每個連接都活躍的情況。

三種情況下：

1.文件描述符數量比較少；

2.每個連接的活躍度都比較高；

3.select可以實現us級別的定時器功能。

有。

半個月前剛改過一個proj，伺服器不支持epoll，只能用select了。

首先我覺得要改正這個觀點，並不是說任何情況下epoll就是最高效的，所有的這些不管是io復用或者各種技術了都是在一定的場景下最高效，我覺得應該說什麼什麼在什麼場景下最適合來表達，不能一味說這個最高效，我們就用這個吧，那個已經out了……就和我們說冒泡排序比選擇排序好一樣，在場景不確定情況下，根本沒有可比性！所以，select和poll還是有適應場景的！

@韋易笑基本說到了，補充一點，select還可以用於監聽普通本地文件的io變化，而epoll不能。