标签：AC top mmap bubuko recv 一个 结构体 时间 回调
同步阻塞式IO开发简单，但在处理IO密集的并发任务时，非常浪费CPU资源，性能低；并且，当一个进程（线程）含有多个套接字上时，同步阻塞式IO会带来问题：因为同步阻塞式IO只支持进程（线程）阻塞在一个套接字上，其余套接字上的事件将得不到及时处理。
为解决这些问题，IO编程的世界诞生了更多的IO模型及实现，这些实现不仅可以用在网络编程中，同样可以用在本地IO编程中。
在此先做说明，阻塞与非阻塞、同步与异步是两组不同的概念。
IO 复用技术是指，调用IO 复用的api（select、pselect、poll、epoll等）时，其阻塞在多个文件描述符（套接字）上，这与普通的阻塞式IO函数如：read、write、close等不同，这些函数都是阻塞在一个文件描述符上。以select为例，select等待多个文件描述符（套接字）上发生IO事件，可以设置等待超时，select只返回描述符就绪的个数（一般可认为是IO事件的个数），用户需要遍扫描整个描述符集处理IO时间。伪代码如下：
|
while(true){ select(描述符集，超时值) for(fd in 描述符集合){ if ( fd has IO事件){ 处理IO事件 } } } |
真实的select要比此复杂，其可指定自己关心的描述符集，分读、写、出错三种描述符集。
Select的缺点很明显，当描述符集很大时，遍历一遍集合的耗时将会很大，因此会有一个FD_SETSIZE宏限制。后续的epoll则优化的此问题，只返回发生的IO事件及其关联的描述符。
非阻塞式IO与阻塞式IO不同的是，非阻塞式IO发现IO暂不可进行时，不阻塞，而是直接返回错误。可结合轮询构成一种可用的模型，但很少见。伪代码如下：
|
while(true) { ret=recv(描述符) if(ret != 错误 && ret != 结束){ 处理IO事件 } } |
信号驱动式IO在IO事件就绪后，向用户程序发送信号或者直接执行回调（调用用户进程空间中的函数），用户在回调函数中执行IO处理。纵观各种读写的IO操作，都是首先等待内核准备好数据或准备好存放数据的内核空间，然后执行内核空间与用户进程空间之间的数据拷贝。其中，信号驱动式IO模型就是在内存做好准备之后，向用户进程发送信号，通知用户进程执行剩下的数据拷贝的操作。以读事件为例，过程如图：
可以看到，信号驱动模式中，读取数据时，依然使用的是同步IO。因此epoll可以说是一种同步非阻塞的支持IO多路复用的IO模型，但是在linux kernel 2.6版本之后，epoll使用了mmap（文件内存映射系统调用），使得数据从内核拷贝到用户进程空间的过程被省略了，于是它有了下面要讲的异步IO的特点，由此进一步产生了epoll到底是异步非阻塞还是同步非阻塞IO模型的一些争议。
异步IO与信号驱动IO模型，仅在于1、通知发生在数据从内核空间读取到用户空间（读）或者数据从用户空间写入到内核空间之后（写）。2、使用的是异步的系统调用api接口。以读为例，过程如图：
可以看到异步IO实在内核已完成IO操作之后，才发起通知，时机不同于信号（事件）驱动式IO。Linux中异步IO系统调用皆以aio_*开头。操作完成之后的通知方式可以是信号，也可以是用户进程空间中的回调函数，皆可通过aiocb结构体设置。目前linux 虽然已有aio函数，但是即使是epoll也并没有直接使用aio，而是通过非阻塞+mmap达到了伪AIO的效果，这与windows iocp和FreeBSD的kqueue纯异步的方案是不同的，普遍的测试结果，epoll性能比iocp还是有微小的差距。
标签：AC top mmap bubuko recv 一个 结构体 时间 回调
原文地址：https://www.cnblogs.com/lvyahui/p/9026060.html
