一、首先列一下，sellect、poll、epoll三者的區(qū)別

　　1、select

　　　　a、select最早于1983年出現(xiàn)在4.2BSD中，它通過一個select()系統(tǒng)調(diào)用來監(jiān)控多個文件描述符的數(shù)組，當(dāng)select返回后，該數(shù)組中就緒的文件描述符便會被內(nèi)核修改標(biāo)志位，使得進程可以獲得這些文件描述符從而進行后續(xù)的讀寫操作。

　　　　b、select目前幾乎在所有的平臺上支持，其良好跨平臺支持也是它的一個優(yōu)點，事實上從現(xiàn)在看來，這也是它所剩不多的優(yōu)點之一。

　　　　c、select的一個缺點在于單個進程能夠監(jiān)視的文件描述符的數(shù)量存在最大限制，在Linux上一般為1024，不可以通過修改宏定義甚至重新編譯內(nèi)核的方式提升這一限制。

　　　　d、另外，select()所維護的存儲大量文件描述符的數(shù)據(jù)結(jié)構(gòu)，隨著文件描述符數(shù)量的增大，其復(fù)制的開銷也線性增長。同時，由于網(wǎng)絡(luò)相應(yīng)時間的延遲使得大量TCP連接處于非活躍狀態(tài)，但調(diào)用select()會對所有

　　2、poll

　　　　a、poll在1986年誕生于System V Release3,它和select在本質(zhì)上沒有多大差別，但是poll沒有最大文件描述符數(shù)量限制。原因是它基于鏈表存儲的。

　　　　b、poll和select同樣存在一個缺點就是，包含大量文件描述符的數(shù)組被整體復(fù)制于用戶態(tài)和內(nèi)核的地址空間之間，而不論這些文件描述符是否就緒，它的開銷隨著文件描述符數(shù)量的增加而線性增大。

　　　　c、select()和poll()將就緒的文件描述符告訴進程后，如果進程沒有對其進行IO操作，那么下次調(diào)用select()和poll()的時候?qū)⒃俅螆蟾孢@些文件描述符，所以他們一般不會丟失就緒的消息，這種方式稱為水平觸發(fā)。

　　3、epoll

　　　　a、直到linux2.6才出現(xiàn)了由內(nèi)核直接支持的實現(xiàn)方法，那就是epoll,它幾乎具備了之前所說的一切優(yōu)點，被公認(rèn)為是linux2.6下性能最好的多路I/O就緒通知方法。

　　　　b、epoll可以同時支持水平出發(fā)和邊緣觸發(fā)(Edge Triggered,只告訴進程哪些文件描述符剛剛變?yōu)榫途w狀態(tài))，只說一遍，如果我們沒有采取行動，那么它將不會再次告知，這種方式稱為邊緣觸發(fā)),理論上邊緣觸發(fā)的性能要更高一些，但是代碼實現(xiàn)相當(dāng)復(fù)雜。

　　　　c、epoll同樣只告知那些就緒的文件描述符，而且當(dāng)我們調(diào)用epoll_wait()獲得就緒文件描述符時，返回的不是實際的描述符，而是一個代表就緒描述符數(shù)量的值，你只需要去epoll指定的一個數(shù)組中依次取得相應(yīng)數(shù)量的文件描述符即可，這里也使用了內(nèi)存映射（mmap）技術(shù)，這樣便徹底省掉了這些文件描述符在系統(tǒng)調(diào)用時復(fù)制的開銷。

　　　　d、另一個本質(zhì)的改進在于epoll采用基于事件的就緒通知方式。在select/poll中，進程只有在調(diào)用一定的方法后，內(nèi)核才會對所有監(jiān)視的文件 描述符進行掃描，而epoll事先通過epoll_ctl()來注冊一個文件描述符，一旦基于某個文件描述符就緒時，內(nèi)核會采用類似callback的回調(diào)機制，迅速激活這個文件描述符，當(dāng)進程調(diào)用epoll_eait()時便得到通知。

轉(zhuǎn)載于:https://www.cnblogs.com/Presley-lpc/p/10079708.html

總結(jié)

以上是生活随笔為你收集整理的Python select解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。