對於接觸過Linux內核或設備驅動開發的讀者，一定清楚poll和select系統調用，以及從2.5版本引入的epoll機制（epoll機制包含三個系統調用）。網上關於它們的文章，有說用法的，甚爲詳細，更有分析源代碼的，又比較深入，且枝節頗多。經過幾篇文章的閱讀，我把覺得比較核心的東西寫下來吧。我的用意是儘可能以簡單的概念，比對他們三者的異同。
幾經查找我才確定下來，poll和select應該被歸類爲這樣的系統調用，它們可以阻塞地同時探測一組支持非阻塞的IO設備，是否有事件發生（如可讀，可寫，有高優先級的錯誤輸出，出現錯誤等等），直至某一個設備觸發了事件或者超過了指定的等待時間——也就是它們的職責不是做IO，而是幫助調用者尋找當前就緒的設備。同類型的產品是Windows的IOCP，它也是處理多路複用，只是把IO和探測封裝在了一起了。
準備的知識有兩點：1、fd；2、op->poll。
在Linux裏面，設備都被抽象爲文件，一系列的設備文件就有自己獨立的虛擬文件系統，所以，設備在系統調用參數中的表示就是file description。fd其實就是一個整數（特別地，標準輸入，輸出，錯誤輸出分別對應的fd是0，1，2）。與內核打交道的時候，傳遞整數的fd可以在自己的文件系統中作進一步的檢查是否合法，如果只是返回指針就不能這樣操作了，畢竟指針是無差別無意義的。
通過fd訪問file，通過file可以訪問其fileOperator，這裏面我們要關心的一個fileOp就是poll。因爲系統調用poll和select，就是依靠這個文件操作poll實現的。poll文件操作有兩個參數，一個是文件本身，一個可以看做是當設備尚未就緒時調用的回調函數，這個函數是把設備自己特有的等待隊列傳給內核，讓內核把當前的進程掛載到其中（因爲當設備就緒時，設備就應該去喚醒在自己特有等待隊列中的所有節點，這樣當前進程就獲取了完成的信號了）。poll文件操作返回的必須是一組標準的掩碼，其中的各個位指示當前的不同的就緒狀態（全0爲沒有任何事件觸發）。
再談談早期多路複用的版本poll和select。
本質而言，poll和select的共同點就是，對全部指定設備做一次poll，當然這往往都是還沒有就緒的，那就會通過回調函數把當前進程註冊到設備的等待隊列，如果所有設備返回的掩碼都沒有顯示任何的事件觸發，就去掉回調函數的函數指針，進入有限時的睡眠狀態，再恢復和不斷做poll，再作有限時的睡眠，直到其中一個設備有事件觸發爲止。只要有事件觸發，系統調用返回，回到用戶態，用戶就可以對相關的fd作進一步的讀或者寫操作了。當然，這個時候還不是所有的設備都就緒的喔，那就得不斷地poll或者select了，而做一次這樣的系統調用都得輪詢所有的設備，次數是設備數*（睡眠次數-1），也就是時間複雜度是O（n），還得做幾次O（n）呢。可見，對於現在普遍的服務器程序，需要同時併發監聽數千個連接，並且連接需要重複使用的情況，poll和select就存在這樣的性能瓶頸。另外，數千個設備fd在每次調用時，都需要將其從用戶空間複製到內核空間，這裏的開銷不可忽略。
poll和select放在一起，是因爲其機制一致，而參數和數據結構就略有不同。select一次性傳入三組作用於不同信道的設備fd，分別是輸入，輸出和錯誤異常。各組的fd期待各組所特有的，由代碼指定的一組事件，如輸入信道期待輸入就緒，輸入掛起和錯誤等事件。 然後，select就挑選調用者關心的fd做poll文件操作，檢測返回的掩碼，看看是否有fd所屬信道感興趣的事件，比如看看這個屬於輸出信道的fd有沒有輸出就緒等一系列的事件發生，一樣地，如果有一個fd發生感興趣事件就返回調用了。select，爲了同時處理三組使用不同的事件判斷規則的fd，採用了位圖的方式表示，一組一個位圖，位長度是當中最大的fd值，上限是1024，三組就是3072，而且這還只是傳入的位圖，還有一樣大小的傳出的位圖。當fd數越來越多時，所需的存儲開銷比較大。
既然，一組fd處理起來比較粗放，那就各個fd自己準備好了。poll()系統調用是System V的多元I/O解決方案。它有三個參數，第一個是pollfd結構的數組指針，也就是指向一組fd及其相關信息的指針，因爲這個結構包含的除了fd，還有期待的事件掩碼和返回的事件掩碼，實質上就是將select的中的fd，傳入和傳出參數歸到一個結構之下，也不再把fd分爲三組，也不再硬性規定fd感興趣的事件，這由調用者自己設定。這樣，不使用位圖來組織數據，也就不需要位圖的全部遍歷了。按照一般隊列地遍歷，每個fd做poll文件操作，檢查返回的掩碼是否有期待的事件，以及做是否有掛起和錯誤的必要性檢查，如果有事件觸發，就可以返回調用了。
回到poll和select的共同點，面對高併發多連接的應用情境，它們顯現出原來沒有考慮到的不足，雖然poll比起select又有所改進了。除了上述的關於每次調用都需要做一次從用戶空間到內核空間的拷貝，還有這樣的問題，就是當處於這樣的應用情境時，poll和select會不得不多次操作，並且每次操作都很有可能需要多次進入睡眠狀態，也就是多次全部輪詢fd，我們應該怎麼處理一些會出現重複而無意義的操作。
這些重複而無意義的操作有：1、從用戶到內核空間拷貝，既然長期監視這幾個fd，甚至連期待的事件也不會改變，那拷貝無疑就是重複而無意義的，我們可以讓內核長期保存所有需要監視的fd甚至期待事件，或者可以再需要時對部分期待事件進行修改；2、將當前線程輪流加入到每個fd對應設備的等待隊列，這樣做無非是哪一個設備就緒時能夠通知進程退出調用，聰明的開發者想到，那就找個“代理”的回調函數，代替當前進程加入fd的等待隊列好了（這也是我後來才總結出來，Linux的等待隊列，實質上是回調函數隊列吧，也可以使用宏來將當前進程“加入”等待隊列，其實就是將喚醒當前進程的回調函數加入隊列）。這樣，像poll系統調用一樣，做poll文件操作發現尚未就緒時，它就調用傳入的一個回調函數，這是epoll指定的回調函數，它不再像以前的poll系統調用指定的回調函數那樣，而是就將那個“代理”的回調函數加入設備的等待隊列就好了，這個代理的回調函數就自己乖乖地等待設備就緒時將它喚醒，然後它就把這個設備fd放到一個指定的地方，同時喚醒可能在等待的進程，到這個指定的地方取fd就好了。我們把1和2結合起來就可以這樣做了，只拷貝一次fd，一旦確定了fd就可以做poll文件操作，如果有事件當然好啦，馬上就把fd放到指定的地方，而通常都是沒有的，那就給這個fd的等待隊列加一個回調函數，有事件就自動把fd放到指定的地方，當前進程不需要再一個個poll和睡眠等待了。
epoll機制就是這樣改進的了。誠然，fd少的時候，當前進程一個個地等問題不大，可是現在和尚多了，方丈就不好管了。以前設備事件觸發時，只負責喚醒當前進程就好了，而當前進程也只能傻傻地在poll裏面等待或者循環，再來一次poll，也不知道這個由設備提供的poll性能如何，能不能檢查出當前進程已經在等待了就立即返回，當然，我也不明白爲什麼做了一遍的poll之後，去掉回調函數指針了，還得再做，不是說好了會去喚醒進程的嗎？
現在就讓事件觸發回調函數多做一步。本來設備還沒就緒就調用一個回調函數了，現在再在這個回調函數裏面做一個註冊另一個回調函數的操作，目的就是使得設備事件觸發多走一步，不僅僅是喚醒當前進程，還要把自己的fd放到指定的地方。就像收本子的班長，以前得一個個學生地去問有沒有本子，如果沒有，它還得等待一段時間而後又繼續問，現在好了，只走一次，如果沒有本子，班長就告訴大家去那裏交本子，當班長想起要取本子，就去那裏看看或者等待一定時間後離開，有本子到了就叫醒他，然後取走。這個道理很簡單，就是老師和班幹們常說的，大家多做一點工作，我的工作就輕鬆很多了，尤其是需要管理的東西越來越多時。
這種機制或者說模式，我想在Java的FutureTask裏面應該也會用到的，一堆在線程池裏面跑着的線程（當然這是任務，不是線程，接口是Callable<V>，不是Runnable.run，是Callable.call，它是可以返回結果的），誰先做好就應該先處理呀，可是難道得一個個問嗎？乾脆就誰好了，誰就按照既定的操作暴露自己，這樣FutureTask的get方法就可以馬上知道當前最先完成的線程了，就可以取此線程返回結果了。
epoll由三個系統調用組成，分別是epoll_create，epoll_ctl和epoll_wait。epoll_create用於創建和初始化一些內部使用的數據結構；epoll_ctl用於添加，刪除或者修改指定的fd及其期待的事件，epoll_wait就是用於等待任何先前指定的fd事件。
關於epoll內部的數據結構，我就不能詳細瞭解了。