select, poll, epoll
IO多路复用里面被广泛使用的select、poll和epoll模型,IO多路复用实现的主旨思想是,不再由应用程序自己监视客户端连接,取而代之由内核替应用程序监视文件
select
/* @Param:
nfds: 监控的文件描述符集里最大文件描述符加1,因为此参数会告诉内核检测前多少个文件描述符的状态
readfds: 监控读数据文件描述符集合,传入传出参数
writefds: 监控写数据文件描述符集合,传入传出参数
exceptfds: 监控异常发生文件描述符集合,如带外数据到达异常,传入传出参数
timeout: 定时阻塞监控时间,3种情况:
1. NULL(永远等下去);
2. 设置timeval,等待固定时间;
3. 设置timeval里时间均为0,检查描述字后立即返回,轮询*/
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
- 使用select模型处理IO请求和同步阻塞模型没有太大的区别,甚至还多了添加监视socket,以及调用select函数的额外操作,效率更差,但select模型可以一个线程内同时处理多个socket的IO请求,即如果处理的连接数不是很高的话,使用select的web server不一定比使用multi-threading + blocking IO的web server性能更好,可能延迟还更大,select的优势并不是对于单个连接能处理得更快,而是在于能处理更多的连接
- 每次调用select,都需要把fd_set集合从用户态拷贝到内核态,如果fd_set集合很大时,那这个开销也很大
- select采用的是轮询模型,每次调用select都需要在内核遍历传递进来的所有fd_set,如果fd_set集合很大时,那这个开销也很大
- 为了减少数据拷贝以及轮询fd_set带来的性能损坏,内核对被监控的fd_set集合大小做了限制,这个是通过宏FD_SETSIZE控制的,一般32位平台为1024,64位平台为2048,单纯改变进程打开的文件描述符个数并不能改变select监听文件个数
poll
/*
@Param
struct pollfd {
int fd; /// 文件描述符
short events; /// 监控的事件
short revents; /// 监控事件中满足条件返回的事件
};
*/
int poll(struct pollfd *fds, nfds_t nfds, int timeout);
一个pollfd结构体表示一个被监视的文件描述符,通过传递fds[]指示 poll() 监视多个文件描述符。其中,结构体的events域是监视该文件描述符的事件掩码,由用户来设置这个域,结构体的revents域是文件描述符的操作结果事件掩码,内核在调用返回时设置这个域。events域中请求的任何事件都可能在revents域中返回。
合法的事件如下:
POLLIN 有数据可读
POLLRDNORM 有普通数据可读
POLLRDBAND 有优先数据可读
POLLPRI 有紧迫数据可读
POLLOUT 写数据不会导致阻塞
POLLWRNORM 写普通数据不会导致阻塞 POLLWRBAND 写优先数据不会导致阻塞 POLLMSGSIGPOLL 消息可用
当需要监听多个事件时,使用POLLIN | POLLRDNORM设置 events 域;当poll调用之后检测某事件是否发生时,fds[i].revents & POLLIN进行判断。
- poll本质上和select没有区别,只是它没有最大连接数的限制,原因是它是基于链表来存储的,它将用户传入的需要监视的文件描述符拷贝到内核空间,然后查询每个fd对应的设备状态,如果设备就绪则在设备等待队列中加入一项并继续遍历,如果遍历完所有fd后没有发现就绪设备,则挂起当前进程,直到设备就绪或者主动超时,被唤醒后它又要再次遍历fd
- poll只解决了select监视文件描述符数量的限制,并没有改变每次调用都需要将文件描述符从程序空间(用户空间)拷贝到内核空间和内核底层轮询所有文件描述符带来的性能开销
epoll
/* 创建一个epoll句柄,参数size用来告诉内核监听的文件描述符的个数,跟内存大小有关 */
int epoll_create(int size);
/* 控制某个epoll监控的文件描述符上的事件:注册、修改、删除 */
/* @Param
epfd: epoll_creat的句柄
op: 表示动作,用3个宏来表示:
EPOLL_CTL_ADD (注册新的fd到epfd),
EPOLL_CTL_MOD (修改已经注册的fd的监听事件),
EPOLL_CTL_DEL (从epfd删除一个fd);
event: 告诉内核需要监听的事件
struct epoll_event {
__uint32_t events; // Epoll events
epoll_data_t data; // User data variable
};
typedef union epoll_data {
void *ptr;
int fd;
uint32_t u32;
uint64_t u64;
} epoll_data_t;
*/
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
/* 等待所监控文件描述符上有事件的产生 */
/* @Param
epfd: epoll_creat的句柄
events: 用来存内核得到事件的集合
maxevents: 告之内核这个events有多大,这个maxevents的值不能大于创建epoll_create()时的size
timeout: 是超时时间
-1: 阻塞
0: 立即返回,非阻塞
>0: 指定毫秒
返回值: 成功返回有多少文件描述符就绪,时间到时返回0,出错返回-1
*/
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)
- epoll是Linux下IO多路复用select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率,因为它会复用文件描述符集合来传递结果而不用迫使开发者每次等待事件之前都必须重新准备要被侦听的文件描述符集合,另一点原因就是获取事件的时候,它无须遍历整个被侦听的描述符集,只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了(采用回调机制,不是轮询的方式,不会随着FD数目的增加效率下降,只有活跃可用的FD才会调用callback函数)
- 虽然表面看起来epoll非常好,但是对于连接数少并且连接都十分活跃的情况下,select和poll的性能可能比epoll好,因为epoll是建立在大量的函数回调的基础之上
- epoll除了提供select/poll那种IO事件的水平触发(Level Triggered,水平触发只要有数据都会触发)外,还提供了边沿触发(Edge Triggered,边缘触发只有数据到来才触发,不管缓存区中是否还有数据),这就使得用户空间程序有可能缓存IO状态,减少epoll_wait/epoll_pwait的调用,提高应用程序效率
epoll有EPOLLLT和EPOLLET两种触发模式,LT是默认的模式,ET是“高速”模式。LT模式下,只要这个fd还有数据可读,每次 epoll_wait都会返回它的事件,提醒用户程序去操作,而在ET(边缘触发)模式中,它只会提示一次,直到下次再有数据流入之前都不会再提示了,无 论fd中是否还有数据可读。所以在ET模式下,read一个fd的时候一定要把它的buffer读光,也就是说一直读到read的返回值小于请求值,或者 遇到EAGAIN错误。还有一个特点是,epoll使用“事件”的就绪通知方式,通过epoll_ctl注册fd,一旦该fd就绪,内核就会采用类似callback的回调机制来激活该fd,epoll_wait便可以收到通知。
使用实例
https://blog.csdn.net/lisongl...
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。