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定義如下：
|
#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()仍然經常使用（多數還是出於習慣，或者打着可移植的名義）：
|
#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察看,一般來說這個數目和系統內存關係很大。
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之上了。
3.使用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的網絡編程中，很長的時間都在使用select來做事件觸發。在linux新的內核中，有了一種替換它的機制，就是epoll。相比於select，epoll最大的好處在於它不會隨着監聽fd數目的增長而降低效率。因爲在內核中的select實現中，它是採用輪詢來處理的，輪詢的fd數目越多，自然耗時越多。並且，在linux/posix_types.h頭文件有這樣的聲明：
#define __FD_SETSIZE 1024
表示select最多同時監聽1024個fd，當然，可以通過修改頭文件再重編譯內核來擴大這個數目，但這似乎並不治本。
epoll的接口非常簡單，一共就三個函數：
1. int epoll_create(int size);
創 建一個epoll的句柄，size用來告訴內核這個監聽的數目一共有多大。這個參數不同於select()中的第一個參數，給出最大監聽的fd+1的值。 需要注意的是，當創建好epoll句柄後，它就是會佔用一個fd值，在linux下如果查看/proc/進程id/fd/，是能夠看到這個fd的，所以在 使用完epoll後，必須調用close()關閉，否則可能導致fd被耗盡。
2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
epoll的事件註冊函數，它不同與select()是在監聽事件時告訴內核要監聽什麼類型的事件，而是在這裏先註冊要監聽的事件類型。第一個參數是epoll_create()的返回值，第二個參數表示動作，用三個宏來表示：
EPOLL_CTL_ADD：註冊新的fd到epfd中；
EPOLL_CTL_MOD：修改已經註冊的fd的監聽事件；
EPOLL_CTL_DEL：從epfd中刪除一個fd；
第三個參數是需要監聽的fd，第四個參數是告訴內核需要監聽什麼事，struct epoll_event結構如下：
struct epoll_event {
__uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};
events可以是以下幾個宏的集合：
EPOLLIN ：表示對應的文件描述符可以讀（包括對端SOCKET正常關閉）；
EPOLLOUT：表示對應的文件描述符可以寫；
EPOLLPRI：表示對應的文件描述符有緊急的數據可讀（這裏應該表示有帶外數據到來）；
EPOLLERR：表示對應的文件描述符發生錯誤；
EPOLLHUP：表示對應的文件描述符被掛斷；
EPOLLET： 將EPOLL設爲邊緣觸發(Edge Triggered)模式，這是相對於水平觸發(Level Triggered)來說的。
EPOLLONESHOT：只監聽一次事件，當監聽完這次事件之後，如果還需要繼續監聽這個socket的話，需要再次把這個socket加入到EPOLL隊列裏
3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
等 待事件的產生，類似於select()調用。參數events用來從內核得到事件的集合，maxevents告之內核這個events有多大，這個 maxevents的值不能大於創建epoll_create()時的size，參數timeout是超時時間（毫秒，0會立即返回，-1將不確定，也有 說法說是永久阻塞）。該函數返回需要處理的事件數目，如返回0表示已超時。
http://blogold.chinaunix.net/u3/98692/showart_2161102.html
今天閒來無事，翻看了下內核代碼，結合內核代碼和大家分享下我的觀點。
一、連接數
我本人也曾經在項目中用過select和epoll,對於select，感觸最深的是linux下select最大數目限制(windows 下似乎沒有限制)，每個進程的select最多能處理FD_SETSIZE個FD(文件句柄)，
如果要處理超過1024個句柄，只能採用多進程了。
常見的使用slect的多進程模型是這樣的： 一個進程專門accept，成功後將fd通過unix socket傳遞給子進程處理，父進程可以根據子進程負載分派。曾經用過1個父進程+4個子進程 承載了超過4000個的負載。
這種模型在我們當時的業務運行的非常好。epoll在連接數方面沒有限制，當然可能需要用戶調用API重現設置進程的資源限制。
二、IO差別
1、select的實現
這段可以結合linux內核代碼描述了，我使用的是2.6.28，其他2.6的代碼應該差不多吧。
先看看select:
select系統調用的代碼在fs/Select.c下，
- asmlinkage long sys_select(int n, fd_set __user *inp, fd_set __user *outp,
- fd_set __user *exp, struct timeval __user *tvp)
- {
- struct timespec end_time, *to = NULL;
- struct timeval tv;
- int ret;
- if (tvp) {
- if (copy_from_user(&tv, tvp, sizeof(tv)))
- return -EFAULT;
- to = &end_time;
- if (poll_select_set_timeout(to,
- tv.tv_sec + (tv.tv_usec / USEC_PER_SEC),
- (tv.tv_usec % USEC_PER_SEC) * NSEC_PER_USEC))
- return -EINVAL;
- }
- ret = core_sys_select(n, inp, outp, exp, to);
- ret = poll_select_copy_remaining(&end_time, tvp, 1, ret);
- return ret;
- }
前面是從用戶控件拷貝各個fd_set到內核空間，接下來的具體工作在core_sys_select中，
core_sys_select->do_select,真正的核心內容在do_select裏：
- int do_select(int n, fd_set_bits *fds, struct timespec *end_time)
- {
- ktime_t expire, *to = NULL;
- struct poll_wqueues table;
- poll_table *wait;
- int retval, i, timed_out = 0;
- unsigned long slack = 0;
- rcu_read_lock();
- retval = max_select_fd(n, fds);
- rcu_read_unlock();
- if (retval < 0)
- return retval;
- n = retval;
- poll_initwait(&table);
- wait = &table.pt;
- if (end_time && !end_time->tv_sec && !end_time->tv_nsec) {
- wait = NULL;
- timed_out = 1;
- }
- if (end_time && !timed_out)
- slack = estimate_accuracy(end_time);
- retval = 0;
- for (;;) {
- unsigned long *rinp, *routp, *rexp, *inp, *outp, *exp;
- set_current_state(TASK_INTERRUPTIBLE);
- inp = fds->in; outp = fds->out; exp = fds->ex;
- rinp = fds->res_in; routp = fds->res_out; rexp = fds->res_ex;
- for (i = 0; i < n; ++rinp, ++routp, ++rexp) {
- unsigned long in, out, ex, all_bits, bit = 1, mask, j;
- unsigned long res_in = 0, res_out = 0, res_ex = 0;
- const struct file_operations *f_op = NULL;
- struct file *file = NULL;
- in = *inp++; out = *outp++; ex = *exp++;
- all_bits = in | out | ex;
- if (all_bits == 0) {
- i += __NFDBITS;
- continue;
- }
- for (j = 0; j < __NFDBITS; ++j, ++i, bit <<= 1) {
- int fput_needed;
- if (i >= n)
- break;
- if (!(bit & all_bits))
- continue;
- file = fget_light(i, &fput_needed);
- if (file) {
- f_op = file->f_op;
- mask = DEFAULT_POLLMASK;
- if (f_op && f_op->poll)
- mask = (*f_op->poll)(file, retval ? NULL : wait);
- fput_light(file, fput_needed);
- if ((mask & POLLIN_SET) && (in & bit)) {
- res_in |= bit;
- retval++;
- }
- if ((mask & POLLOUT_SET) && (out & bit)) {
- res_out |= bit;
- retval++;
- }
- if ((mask & POLLEX_SET) && (ex & bit)) {
- res_ex |= bit;
- retval++;
- }
- }
- }
- if (res_in)
- *rinp = res_in;
- if (res_out)
- *routp = res_out;
- if (res_ex)
- *rexp = res_ex;
- cond_resched();
- }
- wait = NULL;
- if (retval || timed_out || signal_pending(current))
- break;
- if (table.error) {
- retval = table.error;
- break;
- }
- /*
- * If this is the first loop and we have a timeout
- * given, then we convert to ktime_t and set the to
- * pointer to the expiry value.
- */
- if (end_time && !to) {
- expire = timespec_to_ktime(*end_time);
- to = &expire;
- }
- if (!schedule_hrtimeout_range(to, slack, HRTIMER_MODE_ABS))
- timed_out = 1;
- }
- __set_current_state(TASK_RUNNING);
- poll_freewait(&table);
- return retval;
- }
上面的代碼很多，其實真正關鍵的代碼是這一句:
mask = (*f_op->poll)(file, retval ? NULL : wait);
這個是調用文件系統的 poll函數，不同的文件系統poll函數自然不同，由於我們這裏關注的是tcp連接，而socketfs的註冊在 net/Socket.c裏。
register_filesystem(&sock_fs_type);
socket文件系統的函數也是在net/Socket.c裏：
- static const struct file_operations socket_file_ops = {
- .owner = THIS_MODULE,
- .llseek = no_llseek,
- .aio_read = sock_aio_read,
- .aio_write = sock_aio_write,
- .poll = sock_poll,
- .unlocked_ioctl = sock_ioctl,
- #ifdef CONFIG_COMPAT
- .compat_ioctl = compat_sock_ioctl,
- #endif
- .mmap = sock_mmap,
- .open = sock_no_open, /* special open code to disallow open via /proc */
- .release = sock_close,
- .fasync = sock_fasync,
- .sendpage = sock_sendpage,
- .splice_write = generic_splice_sendpage,
- .splice_read = sock_splice_read,
- };
從sock_poll跟隨下去，
最後可以到 net/ipv4/tcp.c的
unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait)
這個是最終的查詢函數，
也就是說select 的核心功能是調用tcp文件系統的poll函數，不停的查詢，如果沒有想要的數據，主動執行一次調度（防止一直佔用cpu），直到有一個連接有想要的消息爲止。
從這裏可以看出select的執行方式基本就是不同的調用poll,直到有需要的消息爲止，如果select 處理的socket很多，這其實對整個機器的性能也是一個消耗。
2、epoll的實現
epoll的實現代碼在 fs/EventPoll.c下，
由於epoll涉及到幾個系統調用，這裏不逐個分析了，僅僅分析幾個關鍵點，
第一個關鍵點在
static int ep_insert(struct eventpoll *ep, struct epoll_event *event,
struct file *tfile, int fd)
這是在我們調用sys_epoll_ctl 添加一個被管理socket的時候調用的函數，關鍵的幾行如下：
epq.epi = epi;
init_poll_funcptr(&epq.pt, ep_ptable_queue_proc);
/*
* Attach the item to the poll hooks and get current event bits.
* We can safely use the file* here because its usage count has
* been increased by the caller of this function. Note that after
* this operation completes, the poll callback can start hitting
* the new item.
*/
revents = tfile->f_op->poll(tfile, &epq.pt);
這裏也是調用文件系統的poll函數，不過這次初始化了一個結構，這個結構會帶有一個poll函數的callback函數：ep_ptable_queue_proc，
在調用poll函數的時候，會執行這個callback，這個callback的功能就是將當前進程添加到 socket的等待進程上。
- static void ep_ptable_queue_proc(struct file *file, wait_queue_head_t *whead,
- poll_table *pt)
- {
- struct epitem *epi = ep_item_from_epqueue(pt);
- struct eppoll_entry *pwq;
- if (epi->nwait >= 0 && (pwq = kmem_cache_alloc(pwq_cache, GFP_KERNEL))) {
- init_waitqueue_func_entry(&pwq->wait, ep_poll_callback);
- pwq->whead = whead;
- pwq->base = epi;
- add_wait_queue(whead, &pwq->wait);
- list_add_tail(&pwq->llink, &epi->pwqlist);
- epi->nwait++;
- } else {
- /* We have to signal that an error occurred */
- epi->nwait = -1;
- }
- }
注意到參數 whead 實際上是 sk->sleep，其實就是將當前進程添加到sk的等待隊列裏，當該socket收到數據或者其他事件觸發時，會調用
sock_def_readable 或者sock_def_write_space 通知函數來喚醒等待進程，這2個函數都是在socket創建的時候填充在sk結構裏的。
從前面的分析來看，epoll確實是比select聰明的多、輕鬆的多，不用再苦哈哈的去輪詢了。
http://buluzhai.iteye.com/blog/1013451
