在linux網絡編程中，很長時間使用select做事件觸發。select會隨著監聽fd的數目的增長而降低效率，因為在實現中，它是采用輪詢的方式處理的，輪詢的fd數目越多，自然耗時就越多。對于IM服務器要支持上萬個鏈接，就顯得力不從心了。而且fd支持數目是有限的，在linux/posix/_types.h頭文件中，有這樣的聲明：#defind __FD_SETSIZE 1024.
epoll則沒有這樣的限制，epoll支持的最大鏈接數是最大可打開的文件的數目。epoll只對活躍的socket進行操作——這是因為epoll是根據每個fd上面的callback函數實現的。那么，只有活躍的socket才會主動地調用callback函數。在一個高速的LAN環境，如果幾乎所有的socket都是活躍的，epoll的效率比select會稍微有下降。
使用mmap加速內核與用戶空間的消息傳遞。無論select，poll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存拷貝，在這點上epoll通過內核與用戶空間mmap同一塊內存空間實現的。
epoll有兩種工作方式LT（level triggered）和ET（edge triggered）。
LT（level triggered）是缺省的工作方式，支持block和non-block socket。在這種模式下，內核告訴你一個文件描述符已經就緒了，然后對這個描述符進行io操作。如果你不作任何操作，內核還會繼續通知你的。所以，這種模式編程出錯可能性要小一點。傳統的select/poll都是這種模型的代表。
ET（edge triggered）高速工作方式，只支持no-block描述符。在這種模式下，當描述符由未就緒變為就緒時，內核通過epoll告訴你。然后它假設你知道文件描述符已經就緒，并且不再為那個描述符發送更多的就緒通知，直到你做了某些操作導致描述符不再是就緒狀態了（比如，你在發送、接收或者接收請求、或者發送接收的數據少于一定量時導致了一個EWOULDBLOCK錯誤）。但是請注意，如果一直不對這個fd作io操作（從而導致它再次變成未就緒），內核不會發送更多的通知（only once），不過在TCP協議中，ET模式的加速效果仍需要更多benchmark確認。
epoll接口
int epoll_create(int size)
創建一個epoll句柄，size告訴內核這個監聽的數目一共有多大。這個參數不同于select的第一個參數，給出最大的fd+1值。需要注意的是，當創建好epoll句柄后，它就會占用一個fd值，在linux下如果查看/proc/prodid/fd/能夠看到這個fd的，所以使用完epoll后，必須調用close關閉。
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)
epoll事件注冊函數，它不同于select是在監聽事件時告訴內核要監聽什么類型的事件，而是在這里先注冊要監聽的事件類型。
epfd：epoll描述符
op：EPOLL_CTL_ADD 注冊新的fd
EPOLL_CTL_MOD 修改已注冊的fd的監聽事件
EPOLL_CTL_DEL 從epfd中刪除一個fd
struct epoll_event {
__uint32_t event; /* EPOLLIN 可以讀（包括對端socket正常關閉）
EPOLLOUT 可以寫
EPOLLPRI 有緊急數據可讀（這里應該表示有帶外數據到來）
EPOLLERR 對應文件描述符發生錯誤
EPOLLHUP 對應的文件描述符被掛斷
EPOLLET ET工作模式
EPOLLONESHOT 只監聽一次事件，當監聽完這次事件后，還需要繼續監聽的話，需要再次把fd加入到監聽隊列里。
epoll_data_t data; /* user data */
};
typedef union epoll_data {
void ptr;
int fd;
__uint32_t u32;
__uint64_t u64;
} epoll_data_t;
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)
等待事件的產生，類似于select。
events，從內核得到事件的總和
maxevents，告訴內核這個events有多大，不能大于epoll_create size 值
timeout，超時時間（毫秒）。0：立即返回，-1 不確定或永久阻塞
返回，0：超時；否則 事件個數
假如有這樣一個例子：
1. 我們已經把一個用來從管道中讀取數據的文件句柄(RFD)添加到epoll描述符
2. 這個時候從管道的另一端被寫入了2KB的數據
3. 調用epoll_wait(2)，并且它會返回RFD，說明它已經準備好讀取操作
4. 然后我們讀取了1KB的數據
5. 調用epoll_wait(2)......
Edge Triggered 工作模式：
如果我們在第1步將RFD添加到epoll描述符的時候使用了EPOLLET標志，那么在第5步調用epoll_wait(2)之后將有可能會掛起，因為剩余的數據還存在于文件的輸入緩沖區內，而且數據發出端還在等待一個針對已經發出數據的反饋信息。只有在監視的文件句柄上發生了某個事件的時候 ET 工作模式才會匯報事件。因此在第5步的時候，調用者可能會放棄等待仍在存在于文件輸入緩沖區內的剩余數據。在上面的例子中，會有一個事件產生在RFD句柄上，因為在第2步執行了一個寫操作，然后，事件將會在第3步被銷毀。因為第4步的讀取操作沒有讀空文件輸入緩沖區內的數據，因此我們在第5步調用 epoll_wait(2)完成后，是否掛起是不確定的。epoll工作在ET模式的時候，必須使用非阻塞套接口，以避免由于一個文件句柄的阻塞讀/阻塞寫操作把處理多個文件描述符的任務餓死。最好以下面的方式調用ET模式的epoll接口，在后面會介紹避免可能的缺陷。
i 基于非阻塞文件句柄
ii 只有當read(2)或者write(2)返回EAGAIN時才需要掛起，等待。但這并不是說每次read()時都需要循環讀，直到讀到產生一個EAGAIN才認為此次事件處理完成，當read()返回的讀到的數據長度小于請求的數據長度時，就可以確定此時緩沖中已沒有數據了，也就可以認為此事讀事件已處理完成。
另外，當使用epoll的ET模型來工作時，當產生了一個EPOLLIN事件后，
讀數據的時候需要考慮的是當recv()返回的大小如果等于請求的大小，那么很有可能是緩沖區還有數據未讀完，也意味著該次事件還沒有處理完，所以還需要再次讀取：
while(rs)
{
buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
if(buflen < 0)
{
// 由于是非阻塞的模式,所以當errno為EAGAIN時,表示當前緩沖區已無數據可讀
// 在這里就當作是該次事件已處理處.
if(errno == EAGAIN)
break;
else
return;
}
else if(buflen == 0)
{
// 這里表示對端的socket已正常關閉.
}
if(buflen == sizeof(buf)
rs = 1; // 需要再次讀取
else
rs = 0;
}
還有，假如發送端流量大于接收端的流量(意思是epoll所在的程序讀比轉發的socket要快),由于是非阻塞的socket,那么send()函數雖然返回,但實際緩沖區的數據并未真正發給接收端,這樣不斷的讀和發，當緩沖區滿后會產生EAGAIN錯誤(參考man send),同時,不理會這次請求發送的數據.所以,需要封裝socket_send()的函數用來處理這種情況,該函數會盡量將數據寫完再返回，返回-1表示出錯。在socket_send()內部,當寫緩沖已滿(send()返回-1,且errno為EAGAIN),那么會等待后再重試.這種方式并不很完美,在理論上可能會長時間的阻塞在socket_send()內部,但暫沒有更好的辦法.
ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)
{
ssize_t tmp;
size_t total = buflen;
const char *p = buffer;
while(1)
{
tmp = send(sockfd, p, total, 0);
if(tmp < 0)
{
// 當send收到信號時,可以繼續寫,但這里返回-1.
if(errno == EINTR)
return -1;
// 當socket是非阻塞時,如返回此錯誤,表示寫緩沖隊列已滿,
// 在這里做延時后再重試.
if(errno == EAGAIN)
{
usleep(1000);
continue;
}
return -1;
}
if((size_t)tmp == total)
return buflen;
total -= tmp;
p += tmp;
}
return tmp;
}