隨着2.6內核對epoll的完全支持，網絡上很多的文章和示例代碼都提供了這樣一個信息：使用epoll代替傳統的poll能給網絡服務應用帶來性能上的提升。但大多文章裏關於性能提升的原因解釋的較少，這裏我將試分析一下內核（2.6.21.1）代碼中poll與epoll的工作原理，然後再通過一些測試數據來對比具體效果。
POLL：
先說poll，poll或select爲大部分Unix/Linux程序員所熟悉，這倆個東西原理類似，性能上也不存在明顯差異，但select對所監控的文件描述符數量有限制，所以這裏選用poll做說明。
poll是一個系統調用，其內核入口函數爲sys_poll，sys_poll幾乎不做任何處理直接調用do_sys_poll，do_sys_poll的執行過程可以分爲三個部分：
1，將用戶傳入的pollfd數組拷貝到內核空間，因爲拷貝操作和數組長度相關，時間上這是一個O（n）操作，這一步的代碼在do_sys_poll中包括從函數開始到調用do_poll前的部分。
2，查詢每個文件描述符對應設備的狀態，如果該設備尚未就緒，則在該設備的等待隊列中加入一項並繼續查詢下一設備的狀態。查詢完所有設備後如果沒有一個設備就緒，這時則需要掛起當前進程等待，直到設備就緒或者超時，掛起操作是通過調用schedule_timeout執行的。設備就緒後進程被通知繼續運行，這時再次遍歷所有設備，以查找就緒設備。這一步因爲兩次遍歷所有設備，時間複雜度也是O（n），這裏面不包括等待時間。相關代碼在do_poll函數中。
3，將獲得的數據傳送到用戶空間並執行釋放內存和剝離等待隊列等善後工作，向用戶空間拷貝數據與剝離等待隊列等操作的的時間複雜度同樣是O（n），具體代碼包括do_sys_poll函數中調用do_poll後到結束的部分。
EPOLL：
接下來分析epoll，與poll/select不同，epoll不再是一個單獨的系統調用，而是由epoll_create/epoll_ctl/epoll_wait三個系統調用組成，後面將會看到這樣做的好處。
先來看sys_epoll_create(epoll_create對應的內核函數），這個函數主要是做一些準備工作，比如創建數據結構，初始化數據並最終返回一個文件描述符（表示新創建的虛擬epoll文件），這個操作可以認爲是一個固定時間的操作。
epoll是做爲一個虛擬文件系統來實現的，這樣做至少有以下兩個好處：
1，可以在內核裏維護一些信息，這些信息在多次epoll_wait間是保持的，比如所有受監控的文件描述符。
2， epoll本身也可以被poll/epoll;
具體epoll的虛擬文件系統的實現和性能分析無關，不再贅述。
在sys_epoll_create中還能看到一個細節，就是epoll_create的參數size在現階段是沒有意義的，只要大於零就行。
接着是sys_epoll_ctl(epoll_ctl對應的內核函數），需要明確的是每次調用sys_epoll_ctl只處理一個文件描述符，這裏主要描述當op爲EPOLL_CTL_ADD時的執行過程，sys_epoll_ctl做一些安全性檢查後進入ep_insert，ep_insert裏將 ep_poll_callback做爲回掉函數加入設備的等待隊列（假定這時設備尚未就緒），由於每次poll_ctl只操作一個文件描述符，因此也可以認爲這是一個O(1)操作
ep_poll_callback函數很關鍵，它在所等待的設備就緒後被系統回掉，執行兩個操作：
1，將就緒設備加入就緒隊列，這一步避免了像poll那樣在設備就緒後再次輪詢所有設備找就緒者，降低了時間複雜度，由O（n）到O（1）;
2，喚醒虛擬的epoll文件;
最後是sys_epoll_wait，這裏實際執行操作的是ep_poll函數。該函數等待將進程自身插入虛擬epoll文件的等待隊列，直到被喚醒（見上面ep_poll_callback函數描述），最後執行ep_events_transfer將結果拷貝到用戶空間。由於只拷貝就緒設備信息，所以這裏的拷貝是一個O(1）操作。
還有一個讓人關心的問題就是epoll對EPOLLET的處理，即邊沿觸發的處理，粗略看代碼就是把一部分水平觸發模式下內核做的工作交給用戶來處理，直覺上不會對性能有太大影響，感興趣的朋友歡迎討論。
POLL/EPOLL對比：
表面上poll的過程可以看作是由一次epoll_create/若干次epoll_ctl/一次epoll_wait/一次close等系統調用構成，實際上epoll將poll分成若干部分實現的原因正是因爲服務器軟件中使用poll的特點（比如Web服務器）：
1，需要同時poll大量文件描述符;
2，每次poll完成後就緒的文件描述符只佔所有被poll的描述符的很少一部分。
3，前後多次poll調用對文件描述符數組（ufds）的修改只是很小;
傳統的poll函數相當於每次調用都重起爐竈，從用戶空間完整讀入ufds，完成後再次完全拷貝到用戶空間，另外每次poll都需要對所有設備做至少做一次加入和刪除等待隊列操作，這些都是低效的原因。
epoll將以上情況都細化考慮，不需要每次都完整讀入輸出ufds，只需使用epoll_ctl調整其中一小部分，不需要每次epoll_wait都執行一次加入刪除等待隊列操作，另外改進後的機制使的不必在某個設備就緒後搜索整個設備數組進行查找，這些都能提高效率。另外最明顯的一點，從用戶的使用來說，使用epoll不必每次都輪詢所有返回結果已找出其中的就緒部分，O（n）變O（1），對性能也提高不少。
此外這裏還發現一點，是不是將epoll_ctl改成一次可以處理多個fd（像semctl那樣）會提高些許性能呢？特別是在假設系統調用比較耗時的基礎上。不過關於系統調用的耗時問題還會在以後分析。
POLL/EPOLL測試數據對比：
測試的環境：我寫了三段代碼來分別模擬服務器，活動的客戶端，僵死的客戶端，服務器運行於一個自編譯的標準2.6.11內核系統上，硬件爲 PIII933，兩個客戶端各自運行在另外的PC上，這兩臺PC比服務器的硬件性能要好，主要是保證能輕易讓服務器滿載，三臺機器間使用一個100M交換機連接。
服務器接受並poll所有連接，如果有request到達則回覆一個response，然後繼續poll。
活動的客戶端（Active Client）模擬若干併發的活動連接，這些連接不間斷的發送請求接受回覆。
僵死的客戶端（zombie）模擬一些只連接但不發送請求的客戶端，其目的只是佔用服務器的poll描述符資源。
測試過程：保持10個併發活動連接，不斷的調整僵併發連接數，記錄在不同比例下使用poll與epoll的性能差別。僵死併發連接數根據比例分別是：0，10，20，40，80，160，320，640，1280，2560，5120，10240。
下圖中橫軸表示僵死併發連接與活動併發連接之比，縱軸表示完成40000次請求回覆所花費的時間，以秒爲單位。紅色線條表示poll數據，綠色表示 epoll數據。可以看出，poll在所監控的文件描述符數量增加時，其耗時呈線性增長，而epoll則維持了一個平穩的狀態，幾乎不受描述符個數影響。
在監控的所有客戶端都是活動時，poll的效率會略高於epoll（主要在原點附近，即僵死併發連接爲0時，圖上不易看出來），究竟epoll實現比poll複雜，監控少量描述符並非它的長處。
POLL：
先說poll，poll或select爲大部分Unix/Linux程序員所熟悉，這倆個東西原理類似，性能上也不存在明顯差異，但select對所監控的文件描述符數量有限制，所以這裏選用poll做說明。
poll是一個系統調用，其內核入口函數爲sys_poll，sys_poll幾乎不做任何處理直接調用do_sys_poll，do_sys_poll的執行過程可以分爲三個部分：
1，將用戶傳入的pollfd數組拷貝到內核空間，因爲拷貝操作和數組長度相關，時間上這是一個O（n）操作，這一步的代碼在do_sys_poll中包括從函數開始到調用do_poll前的部分。
2，查詢每個文件描述符對應設備的狀態，如果該設備尚未就緒，則在該設備的等待隊列中加入一項並繼續查詢下一設備的狀態。查詢完所有設備後如果沒有一個設備就緒，這時則需要掛起當前進程等待，直到設備就緒或者超時，掛起操作是通過調用schedule_timeout執行的。設備就緒後進程被通知繼續運行，這時再次遍歷所有設備，以查找就緒設備。這一步因爲兩次遍歷所有設備，時間複雜度也是O（n），這裏面不包括等待時間。相關代碼在do_poll函數中。
3，將獲得的數據傳送到用戶空間並執行釋放內存和剝離等待隊列等善後工作，向用戶空間拷貝數據與剝離等待隊列等操作的的時間複雜度同樣是O（n），具體代碼包括do_sys_poll函數中調用do_poll後到結束的部分。
EPOLL：
接下來分析epoll，與poll/select不同，epoll不再是一個單獨的系統調用，而是由epoll_create/epoll_ctl/epoll_wait三個系統調用組成，後面將會看到這樣做的好處。
先來看sys_epoll_create(epoll_create對應的內核函數），這個函數主要是做一些準備工作，比如創建數據結構，初始化數據並最終返回一個文件描述符（表示新創建的虛擬epoll文件），這個操作可以認爲是一個固定時間的操作。
epoll是做爲一個虛擬文件系統來實現的，這樣做至少有以下兩個好處：
1，可以在內核裏維護一些信息，這些信息在多次epoll_wait間是保持的，比如所有受監控的文件描述符。
2， epoll本身也可以被poll/epoll;
具體epoll的虛擬文件系統的實現和性能分析無關，不再贅述。
在sys_epoll_create中還能看到一個細節，就是epoll_create的參數size在現階段是沒有意義的，只要大於零就行。
接着是sys_epoll_ctl(epoll_ctl對應的內核函數），需要明確的是每次調用sys_epoll_ctl只處理一個文件描述符，這裏主要描述當op爲EPOLL_CTL_ADD時的執行過程，sys_epoll_ctl做一些安全性檢查後進入ep_insert，ep_insert裏將 ep_poll_callback做爲回掉函數加入設備的等待隊列（假定這時設備尚未就緒），由於每次poll_ctl只操作一個文件描述符，因此也可以認爲這是一個O(1)操作
ep_poll_callback函數很關鍵，它在所等待的設備就緒後被系統回掉，執行兩個操作：
1，將就緒設備加入就緒隊列，這一步避免了像poll那樣在設備就緒後再次輪詢所有設備找就緒者，降低了時間複雜度，由O（n）到O（1）;
2，喚醒虛擬的epoll文件;
最後是sys_epoll_wait，這裏實際執行操作的是ep_poll函數。該函數等待將進程自身插入虛擬epoll文件的等待隊列，直到被喚醒（見上面ep_poll_callback函數描述），最後執行ep_events_transfer將結果拷貝到用戶空間。由於只拷貝就緒設備信息，所以這裏的拷貝是一個O(1）操作。
還有一個讓人關心的問題就是epoll對EPOLLET的處理，即邊沿觸發的處理，粗略看代碼就是把一部分水平觸發模式下內核做的工作交給用戶來處理，直覺上不會對性能有太大影響，感興趣的朋友歡迎討論。
POLL/EPOLL對比：
表面上poll的過程可以看作是由一次epoll_create/若干次epoll_ctl/一次epoll_wait/一次close等系統調用構成，實際上epoll將poll分成若干部分實現的原因正是因爲服務器軟件中使用poll的特點（比如Web服務器）：
1，需要同時poll大量文件描述符;
2，每次poll完成後就緒的文件描述符只佔所有被poll的描述符的很少一部分。
3，前後多次poll調用對文件描述符數組（ufds）的修改只是很小;
傳統的poll函數相當於每次調用都重起爐竈，從用戶空間完整讀入ufds，完成後再次完全拷貝到用戶空間，另外每次poll都需要對所有設備做至少做一次加入和刪除等待隊列操作，這些都是低效的原因。
epoll將以上情況都細化考慮，不需要每次都完整讀入輸出ufds，只需使用epoll_ctl調整其中一小部分，不需要每次epoll_wait都執行一次加入刪除等待隊列操作，另外改進後的機制使的不必在某個設備就緒後搜索整個設備數組進行查找，這些都能提高效率。另外最明顯的一點，從用戶的使用來說，使用epoll不必每次都輪詢所有返回結果已找出其中的就緒部分，O（n）變O（1），對性能也提高不少。
此外這裏還發現一點，是不是將epoll_ctl改成一次可以處理多個fd（像semctl那樣）會提高些許性能呢？特別是在假設系統調用比較耗時的基礎上。不過關於系統調用的耗時問題還會在以後分析。
POLL/EPOLL測試數據對比：
測試的環境：我寫了三段代碼來分別模擬服務器，活動的客戶端，僵死的客戶端，服務器運行於一個自編譯的標準2.6.11內核系統上，硬件爲 PIII933，兩個客戶端各自運行在另外的PC上，這兩臺PC比服務器的硬件性能要好，主要是保證能輕易讓服務器滿載，三臺機器間使用一個100M交換機連接。
服務器接受並poll所有連接，如果有request到達則回覆一個response，然後繼續poll。
活動的客戶端（Active Client）模擬若干併發的活動連接，這些連接不間斷的發送請求接受回覆。
僵死的客戶端（zombie）模擬一些只連接但不發送請求的客戶端，其目的只是佔用服務器的poll描述符資源。
測試過程：保持10個併發活動連接，不斷的調整僵併發連接數，記錄在不同比例下使用poll與epoll的性能差別。僵死併發連接數根據比例分別是：0，10，20，40，80，160，320，640，1280，2560，5120，10240。
下圖中橫軸表示僵死併發連接與活動併發連接之比，縱軸表示完成40000次請求回覆所花費的時間，以秒爲單位。紅色線條表示poll數據，綠色表示 epoll數據。可以看出，poll在所監控的文件描述符數量增加時，其耗時呈線性增長，而epoll則維持了一個平穩的狀態，幾乎不受描述符個數影響。
在監控的所有客戶端都是活動時，poll的效率會略高於epoll（主要在原點附近，即僵死併發連接爲0時，圖上不易看出來），究竟epoll實現比poll複雜，監控少量描述符並非它的長處。
測試代碼及具體數據可以從這裏獲得，歡迎討論。
select()系統調用提供一個機制來實現同步多元I/O：
調用select()將阻塞，直到指定的文件描述符準備好執行I/O，或者可選參數timeout指定的時間已經過去。
監視的文件描述符分爲三類set，每一種對應等待不同的事件。readfds中列出的文件描述符被監視是否有數據可供讀取（如果讀取操作完成則不會阻塞）。writefds中列出的文件描述符則被監視是否寫入操作完成而不阻塞。最後，exceptfds中列出的文件描述符則被監視是否發生異常，或者無法控制的數據是否可用（這些狀態僅僅應用於套接字）。這三類set可以是NULL，這種情況下select()不監視這一類事件。
select()成功返回時，每組set都被修改以使它只包含準備好I/O的文件描述符。例如，假設有兩個文件描述符，值分別是7和9，被放在readfds中。當select()返回時，如果7仍然在set中，則這個文件描述符已經準備好被讀取而不會阻塞。如果9已經不在set中，則讀取它將可能會阻塞（我說可能是因爲數據可能正好在select返回後就可用，這種情況下，下一次調用select()將返回文件描述符準備好讀取）。
第一個參數n，等於所有set中最大的那個文件描述符的值加1。因此，select()的調用者負責檢查哪個文件描述符擁有最大值，並且把這個值加1再傳遞給第一個參數。
timeout參數是一個指向timeval結構體的指針，timeval定義如下：
如果這個參數不是NULL，則即使沒有文件描述符準備好I/O，select()也會在經過tv_sec秒和tv_usec微秒後返回。當select()返回時，timeout參數的狀態在不同的系統中是未定義的，因此每次調用select()之前必須重新初始化timeout和文件描述符set。實際上，當前版本的Linux會自動修改timeout參數，設置它的值爲剩餘時間。因此，如果timeout被設置爲5秒，然後在文件描述符準備好之前經過了3秒，則這一次調用select()返回時tv_sec將變爲2。
如果timeout中的兩個值都設置爲0，則調用select()將立即返回，報告調用時所有未決的事件，但不等待任何隨後的事件。
文件描述符set不會直接操作，一般使用幾個助手宏來管理。這允許Unix系統以自己喜歡的方式來實現文件描述符set。但大多數系統都簡單地實現set爲位數組。FD_ZERO移除指定set中的所有文件描述符。每一次調用select()之前都應該先調用它。
fd_set writefds;
FD_ZERO(&writefds);
FD_SET添加一個文件描述符到指定的set中，FD_CLR則從指定的set中移除一個文件描述符：
FD_SET(fd, &writefds); /* add 'fd' to the set */
FD_CLR(fd, &writefds); /* oops, remove 'fd' from the set */
設計良好的代碼應該永遠不使用FD_CLR，而且實際情況中它也確實很少被使用。
FD_ISSET測試一個文件描述符是否指定set的一部分。如果文件描述符在set中則返回一個非0整數，不在則返回0。FD_ISSET在調用select()返回之後使用，測試指定的文件描述符是否準備好相關動作：
if (FD_ISSET(fd, &readfds))
/* 'fd' is readable without blocking! */
因爲文件描述符set是靜態創建的，它們對文件描述符的最大數目強加了一個限制，能夠放進set中的最大文件描述符的值由FD_SETSIZE指定。在Linux中，這個值是1024。本章後面我們還將看到這個限制的衍生物。
返回值和錯誤代碼
select()成功時返回準備好I/O的文件描述符數目，包括所有三個set。如果提供了timeout，返回值可能是0；錯誤時返回-1，並且設置errno爲下面幾個值之一：
EBADF
給某個set提供了無效文件描述符。
EINTR
等待時捕獲到信號，可以重新發起調用。
EINVAL
參數n爲負數，或者指定的timeout非法。
ENOMEM
不夠可用內存來完成請求。
--------------------------------------------------------------------------------------------------------------
|
#include <sys/time.h> #include <sys/types.h> #include <unistd.h> int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout); FD_CLR(int fd, fd_set *set); FD_ISSET(int fd, fd_set *set); FD_SET(int fd, fd_set *set); FD_ZERO(fd_set *set); |
調用select()將阻塞，直到指定的文件描述符準備好執行I/O，或者可選參數timeout指定的時間已經過去。
監視的文件描述符分爲三類set，每一種對應等待不同的事件。readfds中列出的文件描述符被監視是否有數據可供讀取（如果讀取操作完成則不會阻塞）。writefds中列出的文件描述符則被監視是否寫入操作完成而不阻塞。最後，exceptfds中列出的文件描述符則被監視是否發生異常，或者無法控制的數據是否可用（這些狀態僅僅應用於套接字）。這三類set可以是NULL，這種情況下select()不監視這一類事件。
select()成功返回時，每組set都被修改以使它只包含準備好I/O的文件描述符。例如，假設有兩個文件描述符，值分別是7和9，被放在readfds中。當select()返回時，如果7仍然在set中，則這個文件描述符已經準備好被讀取而不會阻塞。如果9已經不在set中，則讀取它將可能會阻塞（我說可能是因爲數據可能正好在select返回後就可用，這種情況下，下一次調用select()將返回文件描述符準備好讀取）。
第一個參數n，等於所有set中最大的那個文件描述符的值加1。因此，select()的調用者負責檢查哪個文件描述符擁有最大值，並且把這個值加1再傳遞給第一個參數。
timeout參數是一個指向timeval結構體的指針，timeval定義如下：
| #include <sys/time.h> struct timeval { long tv_sec; /* seconds */ long tv_usec; /* 10E-6 second */ }; |
如果這個參數不是NULL，則即使沒有文件描述符準備好I/O，select()也會在經過tv_sec秒和tv_usec微秒後返回。當select()返回時，timeout參數的狀態在不同的系統中是未定義的，因此每次調用select()之前必須重新初始化timeout和文件描述符set。實際上，當前版本的Linux會自動修改timeout參數，設置它的值爲剩餘時間。因此，如果timeout被設置爲5秒，然後在文件描述符準備好之前經過了3秒，則這一次調用select()返回時tv_sec將變爲2。
如果timeout中的兩個值都設置爲0，則調用select()將立即返回，報告調用時所有未決的事件，但不等待任何隨後的事件。
文件描述符set不會直接操作，一般使用幾個助手宏來管理。這允許Unix系統以自己喜歡的方式來實現文件描述符set。但大多數系統都簡單地實現set爲位數組。FD_ZERO移除指定set中的所有文件描述符。每一次調用select()之前都應該先調用它。
fd_set writefds;
FD_ZERO(&writefds);
FD_SET添加一個文件描述符到指定的set中，FD_CLR則從指定的set中移除一個文件描述符：
FD_SET(fd, &writefds); /* add 'fd' to the set */
FD_CLR(fd, &writefds); /* oops, remove 'fd' from the set */
設計良好的代碼應該永遠不使用FD_CLR，而且實際情況中它也確實很少被使用。
FD_ISSET測試一個文件描述符是否指定set的一部分。如果文件描述符在set中則返回一個非0整數，不在則返回0。FD_ISSET在調用select()返回之後使用，測試指定的文件描述符是否準備好相關動作：
if (FD_ISSET(fd, &readfds))
/* 'fd' is readable without blocking! */
因爲文件描述符set是靜態創建的，它們對文件描述符的最大數目強加了一個限制，能夠放進set中的最大文件描述符的值由FD_SETSIZE指定。在Linux中，這個值是1024。本章後面我們還將看到這個限制的衍生物。
返回值和錯誤代碼
select()成功時返回準備好I/O的文件描述符數目，包括所有三個set。如果提供了timeout，返回值可能是0；錯誤時返回-1，並且設置errno爲下面幾個值之一：
EBADF
給某個set提供了無效文件描述符。
EINTR
等待時捕獲到信號，可以重新發起調用。
EINVAL
參數n爲負數，或者指定的timeout非法。
ENOMEM
不夠可用內存來完成請求。
--------------------------------------------------------------------------------------------------------------
poll()系統調用是System V的多元I/O解決方案。它解決了select()的幾個不足，儘管select()仍然經常使用（多數還是出於習慣，或者打着可移植的名義）：
和select()不一樣，poll()沒有使用低效的三個基於位的文件描述符set，而是採用了一個單獨的結構體pollfd數組，由fds指針指向這個組。pollfd結構體定義如下：
每一個pollfd結構體指定了一個被監視的文件描述符，可以傳遞多個結構體，指示poll()監視多個文件描述符。每個結構體的events域是監視該文件描述符的事件掩碼，由用戶來設置這個域。revents域是文件描述符的操作結果事件掩碼。內核在調用返回時設置這個域。events域中請求的任何事件都可能在revents域中返回。合法的事件如下：
POLLIN
有數據可讀。
POLLRDNORM
有普通數據可讀。
POLLRDBAND
有優先數據可讀。
POLLPRI
有緊迫數據可讀。
POLLOUT
寫數據不會導致阻塞。
POLLWRNORM
寫普通數據不會導致阻塞。
POLLWRBAND
寫優先數據不會導致阻塞。
POLLMSG
SIGPOLL消息可用。
此外，revents域中還可能返回下列事件：
POLLER
指定的文件描述符發生錯誤。
POLLHUP
指定的文件描述符掛起事件。
POLLNVAL
指定的文件描述符非法。
這些事件在events域中無意義，因爲它們在合適的時候總是會從revents中返回。使用poll()和select()不一樣，你不需要顯式地請求異常情況報告。
POLLIN | POLLPRI等價於select()的讀事件，POLLOUT | POLLWRBAND等價於select()的寫事件。POLLIN等價於POLLRDNORM | POLLRDBAND，而POLLOUT則等價於POLLWRNORM。
例如，要同時監視一個文件描述符是否可讀和可寫，我們可以設置events爲POLLIN | POLLOUT。在poll返回時，我們可以檢查revents中的標誌，對應於文件描述符請求的events結構體。如果POLLIN事件被設置，則文件描述符可以被讀取而不阻塞。如果POLLOUT被設置，則文件描述符可以寫入而不導致阻塞。這些標誌並不是互斥的：它們可能被同時設置，表示這個文件描述符的讀取和寫入操作都會正常返回而不阻塞。
timeout參數指定等待的毫秒數，無論I/O是否準備好，poll都會返回。timeout指定爲負數值表示無限超時；timeout爲0指示poll調用立即返回並列出準備好I/O的文件描述符，但並不等待其它的事件。這種情況下，poll()就像它的名字那樣，一旦選舉出來，立即返回。
返回值和錯誤代碼
成功時，poll()返回結構體中revents域不爲0的文件描述符個數；如果在超時前沒有任何事件發生，poll()返回0；失敗時，poll()返回-1，並設置errno爲下列值之一：
EBADF
一個或多個結構體中指定的文件描述符無效。
EFAULT
fds指針指向的地址超出進程的地址空間。
EINTR
請求的事件之前產生一個信號，調用可以重新發起。
EINVAL
nfds參數超出PLIMIT_NOFILE值。
ENOMEM
可用內存不足，無法完成請求。
| #include <sys/poll.h> int poll (struct pollfd *fds, unsigned int nfds, int timeout); |
和select()不一樣，poll()沒有使用低效的三個基於位的文件描述符set，而是採用了一個單獨的結構體pollfd數組，由fds指針指向這個組。pollfd結構體定義如下：
| #include <sys/poll.h> struct pollfd { int fd; /* file descriptor */ short events; /* requested events to watch */ short revents; /* returned events witnessed */ }; |
每一個pollfd結構體指定了一個被監視的文件描述符，可以傳遞多個結構體，指示poll()監視多個文件描述符。每個結構體的events域是監視該文件描述符的事件掩碼，由用戶來設置這個域。revents域是文件描述符的操作結果事件掩碼。內核在調用返回時設置這個域。events域中請求的任何事件都可能在revents域中返回。合法的事件如下：
POLLIN
有數據可讀。
POLLRDNORM
有普通數據可讀。
POLLRDBAND
有優先數據可讀。
POLLPRI
有緊迫數據可讀。
POLLOUT
寫數據不會導致阻塞。
POLLWRNORM
寫普通數據不會導致阻塞。
POLLWRBAND
寫優先數據不會導致阻塞。
POLLMSG
SIGPOLL消息可用。
此外，revents域中還可能返回下列事件：
POLLER
指定的文件描述符發生錯誤。
POLLHUP
指定的文件描述符掛起事件。
POLLNVAL
指定的文件描述符非法。
這些事件在events域中無意義，因爲它們在合適的時候總是會從revents中返回。使用poll()和select()不一樣，你不需要顯式地請求異常情況報告。
POLLIN | POLLPRI等價於select()的讀事件，POLLOUT | POLLWRBAND等價於select()的寫事件。POLLIN等價於POLLRDNORM | POLLRDBAND，而POLLOUT則等價於POLLWRNORM。
例如，要同時監視一個文件描述符是否可讀和可寫，我們可以設置events爲POLLIN | POLLOUT。在poll返回時，我們可以檢查revents中的標誌，對應於文件描述符請求的events結構體。如果POLLIN事件被設置，則文件描述符可以被讀取而不阻塞。如果POLLOUT被設置，則文件描述符可以寫入而不導致阻塞。這些標誌並不是互斥的：它們可能被同時設置，表示這個文件描述符的讀取和寫入操作都會正常返回而不阻塞。
timeout參數指定等待的毫秒數，無論I/O是否準備好，poll都會返回。timeout指定爲負數值表示無限超時；timeout爲0指示poll調用立即返回並列出準備好I/O的文件描述符，但並不等待其它的事件。這種情況下，poll()就像它的名字那樣，一旦選舉出來，立即返回。
返回值和錯誤代碼
成功時，poll()返回結構體中revents域不爲0的文件描述符個數；如果在超時前沒有任何事件發生，poll()返回0；失敗時，poll()返回-1，並設置errno爲下列值之一：
EBADF
一個或多個結構體中指定的文件描述符無效。
EFAULT
fds指針指向的地址超出進程的地址空間。
EINTR
請求的事件之前產生一個信號，調用可以重新發起。
EINVAL
nfds參數超出PLIMIT_NOFILE值。
ENOMEM
可用內存不足，無法完成請求。
--------------------------------------------------------------------------------------------------------------
以上內容來自《OReilly.Linux.System.Programming - Talking.Directly.to.the.Kernel.and.C.Library.2007》
--------------------------------------------------------------------------------------------------------------
epoll的優點：
1.支持一個進程打開大數目的socket描述符(FD)
select 最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設置，默認值是2048。對於那些需要支持的上萬連接數目的IM服務器來說顯然太少了。這時候你一是可以選擇修改這個宏然後重新編譯內核，不過資料也同時指出這樣會帶來網絡效率的下降，二是可以選擇多進程的解決方案(傳統的 Apache方案)，不過雖然linux上面創建進程的代價比較小，但仍舊是不可忽視的，加上進程間數據同步遠比不上線程間同步的高效，所以也不是一種完美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大於2048,舉個例子,在1GB內存的機器上大約是10萬左右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統內存關係很大。
1.支持一個進程打開大數目的socket描述符(FD)
select 最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設置，默認值是2048。對於那些需要支持的上萬連接數目的IM服務器來說顯然太少了。這時候你一是可以選擇修改這個宏然後重新編譯內核，不過資料也同時指出這樣會帶來網絡效率的下降，二是可以選擇多進程的解決方案(傳統的 Apache方案)，不過雖然linux上面創建進程的代價比較小，但仍舊是不可忽視的，加上進程間數據同步遠比不上線程間同步的高效，所以也不是一種完美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大於2048,舉個例子,在1GB內存的機器上大約是10萬左右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統內存關係很大。
2.IO效率不隨FD數目增加而線性下降
傳統的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由於網絡延時，任一時間只有部分的socket是"活躍"的，但是select/poll每次調用都會線性掃描全部的集合，導致效率呈現線性下降。但是epoll不存在這個問題，它只會對"活躍"的socket進行操作---這是因爲在內核實現中epoll是根據每個fd上面的callback函數實現的。那麼，只有"活躍"的socket纔會主動的去調用 callback函數，其他idle狀態socket則不會，在這點上，epoll實現了一個"僞"AIO，因爲這時候推動力在os內核。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個高速LAN環境，epoll並不比select/poll有什麼效率，相反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環境,epoll的效率就遠在select/poll之上了。
傳統的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由於網絡延時，任一時間只有部分的socket是"活躍"的，但是select/poll每次調用都會線性掃描全部的集合，導致效率呈現線性下降。但是epoll不存在這個問題，它只會對"活躍"的socket進行操作---這是因爲在內核實現中epoll是根據每個fd上面的callback函數實現的。那麼，只有"活躍"的socket纔會主動的去調用 callback函數，其他idle狀態socket則不會，在這點上，epoll實現了一個"僞"AIO，因爲這時候推動力在os內核。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個高速LAN環境，epoll並不比select/poll有什麼效率，相反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環境,epoll的效率就遠在select/poll之上了。
3.使用mmap加速內核與用戶空間的消息傳遞。
這點實際上涉及到epoll的具體實現了。無論是select,poll還是epoll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存拷貝就很重要，在這點上，epoll是通過內核於用戶空間mmap同一塊內存實現的。而如果你想我一樣從2.5內核就關注epoll的話，一定不會忘記手工 mmap這一步的。
這點實際上涉及到epoll的具體實現了。無論是select,poll還是epoll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存拷貝就很重要，在這點上，epoll是通過內核於用戶空間mmap同一塊內存實現的。而如果你想我一樣從2.5內核就關注epoll的話，一定不會忘記手工 mmap這一步的。
4.內核微調
這一點其實不算epoll的優點了，而是整個linux平臺的優點。也許你可以懷疑linux平臺，但是你無法迴避linux平臺賦予你微調內核的能力。比如，內核TCP/IP協議棧使用內存池管理sk_buff結構，那麼可以在運行時期動態調整這個內存pool(skb_head_pool)的大小--- 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數的第2個參數(TCP完成3次握手的數據包隊列長度)，也可以根據你平臺內存大小動態調整。更甚至在一個數據包面數目巨大但同時每個數據包本身大小卻很小的特殊系統上嘗試最新的NAPI網卡驅動架構。
這一點其實不算epoll的優點了，而是整個linux平臺的優點。也許你可以懷疑linux平臺，但是你無法迴避linux平臺賦予你微調內核的能力。比如，內核TCP/IP協議棧使用內存池管理sk_buff結構，那麼可以在運行時期動態調整這個內存pool(skb_head_pool)的大小--- 通過echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函數的第2個參數(TCP完成3次握手的數據包隊列長度)，也可以根據你平臺內存大小動態調整。更甚至在一個數據包面數目巨大但同時每個數據包本身大小卻很小的特殊系統上嘗試最新的NAPI網卡驅動架構。