select系统调用
select系统调用允许程序同时在多个底层文件描述符上等待输入的到达（或输出的完成）。这意味着终端程序可以阻塞到有事情可做为止。类似的，服务器也可以通过同时在多个打开的套接字上等待请求到来的方法来处理程序。
select实现
1、使用copy_from_user从用户空间拷贝fd_set到内核空间
2、注册回调函数__pollwait
3、遍历所有fd，调用其对应的poll方法（对于socket，这个poll方法是sock_poll，sock_poll根据情况会调用到tcp_poll,udp_poll或者datagram_poll）
4、以tcp_poll为例，其核心实现就是__pollwait，也就是上面注册的回调函数。
5、__pollwait的主要工作就是把current（当前进程）挂到设备的等待队列中，不同的设备有不同的等待队列，对于tcp_poll来说，其等待队列是sk->sk_sleep（注意把进程挂到等待队列中并不代表进程已经睡眠了）。在设备收到一条消息（网络设备）或填写完文件数据（磁盘设备）后，会唤醒设备等待队列上睡眠的进程，这时current便被唤醒了。
6、poll方法返回时会返回一个描述读写操作是否就绪的mask掩码，根据这个mask掩码给fd_set赋值。
7、如果遍历完所有的fd，还没有返回一个可读写的mask掩码，则会调用schedule_timeout是调用select的进程（也就是current）进入睡眠。当设备驱动发生自身资源可读写后，会唤醒其等待队列上睡眠的进程。如果超过一定的超时时间（schedule_timeout指定），还是没人唤醒，则调用select的进程会重新被唤醒获得CPU，进而重新遍历fd，判断有没有就绪的fd。
8、把fd_set从内核空间拷贝到用户空间。
select的几大缺点：
（1）每次调用select，都需要把fd集合从用户态拷贝到内核态，这个开销在fd很多时会很大
（2）同时每次调用select都需要在内核遍历传递进来的所有fd，这个开销在fd很多时也很大
（3）select支持的文件描述符数量太小了，默认是1024
select()函数的接口主要是建立在一种叫'fd_set'类型的基础上。它('fd_set') 是一组文件描述符(fd)的集合。由于fd_set类型的长度在不同平台上不同，因此应该用一组标准的宏定义来处理此类变量：
1 fd_set set; 2 FD_ZERO(&set); /* 将set清零 */ 3 FD_SET(fd, &set); /* 将fd加入set */ 4 FD_CLR(fd, &set); /* 将fd从set中清除 */ 5 FD_ISSET(fd, &set); /* 如果fd在set中则真 */
在过去，一个fd_set通常只能包含少于等于32个文件描述符，因为fd_set其实只用了一个int的比特量来实现，在大多数情况下，检查 fd_set能包括任意值的文件描述符是系统的责任，但确定你的fd_set到底能放多少有时你应该检查/修改宏FD_SETSIZE的值。*这个值是系统相关的*，同时检查你的系统中的select() 的man手册。有一些系统对多于1024个文件描述符的支持有问题。[Linux就是这样的系统！你会发现sizeof(fd_set)的结果是128(*8 = FD_SETSIZE=1024) 尽管很少你会遇到这种情况。]
select的基本接口：
int select(int nfds, fd_set *readset, fd_set *writeset, fd_set *exceptset, struct timeval *timeout);
其中：
nfds
需要检查的文件描述符个数，数值应该比是三组fd_set中最大数更大，而不是实际文件描述符的总数。
readset
用来检查可读性的一组文件描述符。
writeset
用来检查可写性的一组文件描述符。
exceptset
用来检查意外状态的文件描述符。(注：错误并不是意外状态)
timeout
NULL指针代表无限等待，否则是指向timeval结构的指针，代表最长等待时间。(如果其中tv_sec和tv_usec都等于0, 则文件描述符的状态不被影响，但函数并不挂起)
poll系统调用
poll与select为大部分Unix/Linux程序员所熟悉，这俩个东西原理类似，性能上也不存在明显差异，但select对所监控的文件描述符数量有限制。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后到结束的部分。
#include <poll.h> int poll(struct pollfd fds[], nfds_t nfds, int timeout)；
参数说明:
fds：是一个struct pollfd结构类型的数组，用于存放需要检测其状态的Socket描述符；每当调用这个函数之后，系统不会清空这个数组，操作起来比较方便；特别是对于socket连接比较多的情况下，在一定程度上可以提高处理的效率；这一点与select()函数不同，调用select()函数之后，select()函数会清空它所检测的socket描述符集合，导致每次调用select()之前都必须把socket描述符重新加入到待检测的集合中；因此，select()函数适合于只检测一个socket描述符的情况，而poll()函数适合于大量socket描述符的情况；
nfds：nfds_t类型的参数，用于标记数组fds中的结构体元素的总数量；
timeout：是poll函数调用阻塞的时间，单位：毫秒；
返回值:
>0：数组fds中准备好读、写或出错状态的那些socket描述符的总数量；
==0：数组fds中没有任何socket描述符准备好读、写，或出错；此时poll超时，超时时间是timeout毫秒；换句话说，如果所检测的socket描述符上没有任何事件发生的话，那么poll()函数会阻塞timeout所指定的毫秒时间长度之后返回，如果timeout==0，那么poll() 函数立即返回而不阻塞，如果timeout==INFTIM，那么poll() 函数会一直阻塞下去，直到所检测的socket描述符上的感兴趣的事件发生是才返回，如果感兴趣的事件永远不发生，那么poll()就会永远阻塞下去；
-1： poll函数调用失败，同时会自动设置全局变量errno；
如果待检测的socket描述符为负值，则对这个描述符的检测就会被忽略，也就是不会对成员变量events进行检测，在events上注册的事件也会被忽略，poll()函数返回的时候，会把成员变量revents设置为0，表示没有事件发生；
另外，poll() 函数不会受到socket描述符上的O_NDELAY标记和O_NONBLOCK标记的影响和制约，也就是说，不管socket是阻塞的还是非阻塞的，poll()函数都不会收到影响；而select()函数则不同，select()函数会受到O_NDELAY标记和O_NONBLOCK标记的影响，如果socket是阻塞的socket，则调用select()跟不调用select()时的效果是一样的，socket仍然是阻塞式TCP通讯，相反，如果socket是非阻塞的socket，那么调用select()时就可以实现非阻塞式TCP通讯；
所以poll() 函数的功能和返回值的含义与 select() 函数的功能和返回值的含义是完全一样的，两者之间的差别就是内部实现方式不一样，select()函数基本上可以在所有支持文件描述符操作的系统平台上运行(如：Linux 、Unix 、Windows、MacOS等)，可移植性好，而poll()函数则只有个别的的操作系统提供支持(如：SunOS、Solaris、AIX、HP提供支持，但是Linux不提供支持)，可移植性差；
strust pollfd结构说明：
typedef struct pollfd { int fd; /* 需要被检测或选择的文件描述符*/ short events; /* 对文件描述符fd上感兴趣的事件 */ short revents; /* 文件描述符fd上当前实际发生的事件*/ } pollfd_t; typedef unsigned long nfds_t;
经常检测的事件标记： POLLIN/POLLRDNORM(可读)、POLLOUT/POLLWRNORM(可写)、POLLERR(出错)
如果是对一个描述符上的多个事件感兴趣的话，可以把这些常量标记之间进行按位或运算就可以了；
比如：对socket描述符fd上的读、写、异常事件感兴趣，就可以这样做：struct pollfd fds;
fds[nIndex].events=POLLIN | POLLOUT | POLLERR；
当 poll()函数返回时，要判断所检测的socket描述符上发生的事件，可以这样做： struct pollfd fds;
检测可读TCP连接请求：
if((fds[nIndex].revents & POLLIN) == POLLIN){//接收数据/调用accept()接收连接请求}
检测可写：
if((fds[nIndex].revents & POLLOUT) == POLLOUT){//发送数据}
检测异常：
if((fds[nIndex].revents & POLLERR) == POLLERR){//异常处理}
epoll系统调用
与poll/select不同，epoll不再是一个单独的系统调用，而是由epoll_create/epoll_ctl/epoll_wait三个系统调用组成，后面将会看到这样做的好处。
先来看sys_epoll_create(epoll_create对应的内核函数），这个函数主要是做一些准备工作，比如创建数据结构，初始化数据并最终返回一个文件描述符（表示新创建的虚拟epoll文件），这个操作可以认为是一个固定时间的操作。
epoll是做为一个虚拟文件系统来实现的，这样做至少有以下两个好处：
1、可以在内核里维护一些信息，这些信息在多次epoll_wait间是保持的，比如所有受监控的文件描述符。
2、 epoll本身也可以被poll/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关键数据：
1 struct epoll_event { 2 3 __uint32_t events; // Epoll events 4 5 epoll_data_t data; // User data variable 6 7 }; 8 9 typedef union epoll_data { 10 11 void *ptr; 12 13 int fd; 14 15 __uint32_t u32; 16 17 __uint64_t u64; 18 19 } epoll_data_t;
使用epoll：
int epoll_create(int size);
生成一个 epoll 专用的文件描述符，其实是申请一个内核空间，用来存放你想关注的 socket fd 上是否发生以及发生了什么事件。 size 就是你在这个 epoll fd 上能关注的最大 socket fd 数，大小自定，只要内存足够。
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event );
控制某个 epoll 文件描述符上的事件：注册、修改、删除。其中参数 epfd 是 epoll_create() 创建 Epoll 专用的文件描述符。相对于 select 模型中的 FD_SET 和 FD_CLR 宏。
int epoll_wait(int epfd,struct epoll_event * events,int maxevents,int timeout);
等待 I/O 事件的发生；
参数说明：
epfd: 由 epoll_create() 生成的 Epoll 专用的文件描述符；
epoll_event: 用于回传代处理事件的数组；
maxevents: 每次能处理的事件数；
timeout: 等待 I/O 事件发生的超时值；
返回发生事件数。
相对于 select 模型中的 select 函数。
比较
1、select，poll实现需要自己不断轮询所有fd集合，直到设备就绪，期间可能要睡眠和唤醒多次交替。而epoll其实也需要调用epoll_wait不断轮询就绪链表，期间也可能多次睡眠和唤醒交替，但是它是设备就绪时，调用回调函数，把就绪fd放入就绪链表中，并唤醒在epoll_wait中进入睡眠的进程。虽然都要睡眠和交替，但是select和poll在“醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，这节省了大量的CPU时间。这就是回调机制带来的性能提升。
2、select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，并且要把current往设备等待队列中挂一次，而epoll只要一次拷贝，而且把current往等待队列上挂也只挂一次（在epoll_wait的开始，注意这里的等待队列并不是设备等待队列，只是一个epoll内部定义的等待队列）。这也能节省不少的开销。
3、传统的poll函数相当于每次调用都重起炉灶，从用户空间完整读入ufds，完成后再次完全拷贝到用户空间，另外每次poll都需要对所有设备做至少做一次加入和删除等待队列操作，这些都是低效的原因。epoll将以上情况都细化考虑，不需要每次都完整读入输出ufds，只需使用epoll_ctl调整其中一小部分，不需要每次epoll_wait都执行一次加入删除等待队列操作，另外改进后的机制使的不必在某个设备就绪后搜索整个设备数组进行查找，这些都能提高效率。另外最明显的一点，从用户的使用来说，使用epoll不必每次都轮询所有返回结果已找出其中的就绪部分，O（n）变O（1），对性能也提高不少。
4、传统的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之上了。