select.poll,epoll的区别与应用

先讲讲同步I/O的五大模型

阻塞式I/O，非阻塞式I/O， I/O复用，信号驱动I/O(SIGIO),异步I/O模型

而select/poll/epoll属于I/O复用模型

select函数

该函数允许进程指示内核等待多个事件中的任何一个发生，并只在有一个或多个事件发生或经历一段指定的时间后才能唤醒它
#include <sys/select.h>
#include <sys/time.h>
int select(int maxfdp1, fd_set *readset, fd_set *writeset, fd_set *excspeset, const struct timeval *timeout)

如何指定一个或多个描述符，这由fd_set的数据类型和以下四个宏控制

void FD_ZERO(fd_set *fdset) //clear all bits in fdset
void FD_SET(int fd, fd_set *fdset) //turn on the bit for fd in fdset
void FD_CLR(int fd, fd_set *fdset) //turn off the bit for fd in fdset

void FD_ISSET(int fd, fd_set *fdset) //is the bit for fd on in fdset

struct timeval

{

int sec;

int usec;

};

1. 该参数用以指明等待的时间:
a) 永远等待,则设置 NULL 指针
b) 不等待立即返回,那么设置该结构中 2 个成员值都设为 0
c) 等待一定时间就必须具体设置

poll函数

与select函数相似，但它提供额外的信息
#include<poll.h>
int poll(struct pollfd *fdarray, unsigned long nfds, int timeout);
struct follfd
{
int fd; //decriptior to check
short events; //events of internet on fd
short revents; //eventd that occured on fd
};

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后到结束的部分。

poll与select的不足点

1. 每次调用都需要做一次从用户空间到内核空间的拷贝

2. 每次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）的修改只是很小;

epoll的优点

1. 支持一个进程打开大数目的socket描述符(FD)

2.IO效率不随FD数目增加而线性下降

3.使用共享内存加速内核与用户空间的消息传递。

转载自http://www.embeddedlinux.org.cn/html/yingjianqudong/201303/11-2477.html