概述 

   邊緣觸發(fā) 是指每當(dāng)狀態(tài)變化時發(fā)生一個io事件；

   條件觸發(fā) 是只要滿足條件就發(fā)生一個io事件；

詳述 

                int select(int n, fd_set *rd_fds, fd_set *wr_fds, fd_set *ex_fds, struct timeval *timeout);
     select用到了fd_set結(jié)構(gòu),此處有一個FD_SETSIZE決定fd_set的容量，F(xiàn)D_SETSIZE默認(rèn)1024，可以通過ulimit -n或者setrlimit函數(shù)修改之。
                int poll(struct pollfd *ufds, unsigned int nfds, int timeout);
     作為select的替代品，poll的參數(shù)用struct pollfd數(shù)組(第一個參數(shù))來取代fd_set，數(shù)組大小自己定義，這樣的話避免了FD_SETSIZE給程序帶來的麻煩。
     每次的 select/poll操作，都需要建立當(dāng)前線程的關(guān)心事件列表，并掛起此線程到等待隊列中 直到事件觸發(fā)或者timeout結(jié)束，同時select/poll返回后也需要對傳入的句柄列表做一次掃描來dispatch。隨著連接數(shù)增 加，select和poll的性能是嚴(yán)重非線性下降。

epoll(linux), kqueue(freebsd), /dev/poll(solaris):
作為針對select和poll的升級（可以這么理解:)）,主要它們做了兩件事情

1. 避免了每次調(diào)用select/poll時kernel分析參數(shù)建立事件等待結(jié)構(gòu)的開銷，kernel維護(hù)一個長期的事件關(guān)注列表，應(yīng)用程序通過句柄修改這個列表和捕獲I/O事件。
2. 避免了select/poll返回后，應(yīng)用程序掃描整個句柄表的開銷，Kernel直接返回具體的事件列表給應(yīng)用程序。

同時還有兩種觸發(fā)機(jī)制：
水平觸發(fā)(level-triggered，也被稱為條件觸發(fā))LT: 只要滿足條件，就觸發(fā)一個事件(只要有數(shù)據(jù)沒有被獲取，內(nèi)核就不斷通知你)
邊緣觸發(fā)(edge-triggered)ET: 每當(dāng)狀態(tài)變化時，觸發(fā)一個事件
     “舉個讀socket的例子，假定經(jīng)過長時間的沉默后，現(xiàn)在來了100個字節(jié)，這時無論邊緣觸發(fā)和條件觸發(fā)都會產(chǎn)生一個read ready notification通知應(yīng)用程序可讀。應(yīng)用程序讀了50個字節(jié)，然后重新調(diào)用api等待io事件。這時條件觸發(fā)的api會因為還有50個字節(jié)可讀從 而立即返回用戶一個read ready notification。而邊緣觸發(fā)的api會因為可讀這個狀態(tài)沒有發(fā)生變化而陷入長期等待。 因此在使用邊緣觸發(fā)的api時，要注意每次都要讀到socket返回EWOULDBLOCK為止，否則這個socket就算廢了。而使用條件觸發(fā)的api 時，如果應(yīng)用程序不需要寫就不要關(guān)注socket可寫的事件，否則就會無限次的立即返回一個write ready notification。大家常用的select就是屬于條件觸發(fā)這一類，長期關(guān)注socket寫事件會出現(xiàn)CPU 100%的毛病。

epoll的優(yōu)點(diǎn)： 
1.支持一個進(jìn)程打開大數(shù)目的socket描述符(FD) 
    select 最不能忍受的是一個進(jìn)程所打開的FD是有一定限制的，由FD_SETSIZE設(shè)置，默認(rèn)值是2048。對于那些需要支持的上萬連接數(shù)目的IM服務(wù)器來說顯 然太少了。這時候你一是可以選擇修改這個宏然后重新編譯內(nèi)核，不過資料也同時指出這樣會帶來網(wǎng)絡(luò)效率的下降，二是可以選擇多進(jìn)程的解決方案(傳統(tǒng)的 Apache方案)，不過雖然linux上面創(chuàng)建進(jìn)程的代價比較小，但仍舊是不可忽視的，加上進(jìn)程間數(shù)據(jù)同步遠(yuǎn)比不上線程間同步的高效，所以也不是一種完 美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數(shù)目，這個數(shù)字一般遠(yuǎn)大于2048,舉個例子,在1GB內(nèi)存的機(jī)器上大約是10萬左 右，具體數(shù)目可以cat /proc/sys/fs/file-max察看,一般來說這個數(shù)目和系統(tǒng)內(nèi)存關(guān)系很大。

2.IO效率不隨FD數(shù)目增加而線性下降 
    傳統(tǒng)的select/poll另一個致命弱點(diǎn)就是當(dāng)你擁有一個很大的socket集合，不過由于網(wǎng)絡(luò)延時，任一時間只有部分的socket是"活躍"的， 但是select/poll每次調(diào)用都會線性掃描全部的集合，導(dǎo)致效率呈現(xiàn)線性下降。但是epoll不存在這個問題，它只會對"活躍"的socket進(jìn)行 操作---這是因為在內(nèi)核實(shí)現(xiàn)中epoll是根據(jù)每個fd上面的callback函數(shù)實(shí)現(xiàn)的。那么，只有"活躍"的socket才會主動的去調(diào)用 callback函數(shù)，其他idle狀態(tài)socket則不會，在這點(diǎn)上，epoll實(shí)現(xiàn)了一個"偽"AIO，因為這時候推動力在os內(nèi)核。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個高速LAN環(huán)境，epoll并不比select/poll有什么效率，相 反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環(huán)境,epoll的效率就遠(yuǎn)在select/poll之上了。

3.使用mmap加速內(nèi)核與用戶空間的消息傳遞。 
    這點(diǎn)實(shí)際上涉及到epoll的具體實(shí)現(xiàn)了。無論是select,poll還是epoll都需要內(nèi)核把FD消息通知給用戶空間，如何避免不必要的內(nèi)存拷貝就 很重要，在這點(diǎn)上，epoll是通過內(nèi)核于用戶空間mmap同一塊內(nèi)存實(shí)現(xiàn)的。而如果你想我一樣從2.5內(nèi)核就關(guān)注epoll的話，一定不會忘記手工 mmap這一步的。

4.內(nèi)核微調(diào) 
    這一點(diǎn)其實(shí)不算epoll的優(yōu)點(diǎn)了，而是整個linux平臺的優(yōu)點(diǎn)。也許你可以懷疑linux平臺，但是你無法回避linux平臺賦予你微調(diào)內(nèi)核的能力。 比如，內(nèi)核TCP/IP協(xié)議棧使用內(nèi)存池管理sk_buff結(jié)構(gòu)，那么可以在運(yùn)行時期動態(tài)調(diào)整這個內(nèi)存pool(skb_head_pool)的大小 --- 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數(shù)的第2個參數(shù)(TCP完成3次握手 的數(shù)據(jù)包隊列長度)，也可以根據(jù)你平臺內(nèi)存大小動態(tài)調(diào)整。更甚至在一個數(shù)據(jù)包面數(shù)目巨大但同時每個數(shù)據(jù)包本身大小卻很小的特殊系統(tǒng)上嘗試最新的NAPI網(wǎng) 卡驅(qū)動架構(gòu)。 ?