Note5：多路复用

1. 读多个文件怎么办

比如我们要写一个程序（要求如下）：
1.读GPS的信息；
2.读socket里面的内容控制灯；
3.读串口内容。

while(1)
{
	read(gps_fd, buf, sizeof(buf) );
	read(socket_fd, buf, sizeof(buf) );			//socket_fd 会阻塞，要等待上一个函数结束
	read(serialport_fd, buf, sizeof(buf) );		//serialport 也会阻塞，要等待上一个函数结束
}

为了解决这个阻塞的问题，我们通过线程来解决

// 结构体
struct worker_ctx
{	
	int fd;
	...
} ctx;

// 主线程
pthread_create(&tid, &thread_attr, gps_worker, (void *)&ctx);	// &ctx取结构体的地址
pthread_create(&tid, &thread_attr, socket_worker, arg);
pthread_create(&tid, &thread_attr, serialport_worker, arg);

// 子线程
void *gps_worker(void *arg)	// 如果有n个东西传送。请用结构体打包
{
	struct worker_ctx *ctx=(worker_ctx *)arg;
	while(1)
	{
		read(gps_fd, buf, sizeof(buf) );
	}
}

2. 多进程和多线程的理解

多线程：主线程是你爸妈的房间，子线程是你的房间，你们要吃饼干，都只要在客厅里面拿就可以。
多进程：你爸妈的房间在一层楼，你的房间在另外一层楼，两个房间的通信用IPC协议，我们用的socket就是这种协议。
所以多线程比较方便！！！

但是创建线程和进程都会耗费时间。比如我们开一个餐馆，来一个客户我们座位不够，我们就要去买一个凳子给他坐，又来一个客户，我们又要买一个凳子…这样就很慢，我们大量时间都在买凳子上！我们为了改进，我们就创建一个进程（线程）池——process（thread） pool——我们事先准备好凳子！这样就快一点！但是我们创建池不知道客户究竟来多少，我们凳子有可能多，也有可能少！

3. 用多路复用的原因

把三个文件描述符打包进行监听

while(1)
{
	some_set_add(set, gps_fd);		//把文件描述符加进set集合中
	some_set_add(set, socket_fd);
	some_set_add(set, serialport_fd);

	rv = some_function(set);		//监听set集合
	if( is(gps_fd) )			//用了if就不会阻塞
	{
		read(gps_fd, buf, sizeof(buf) );
	}
	else if( is(socket_fd) )
	{
		read(socket_fd, buf, sizeof(buf) );
	}
	else if( is(serialport_fd) )
	{
		read(serialport_fd, buf, sizeof(buf) );
	}
}

4. 五种网络I/O模型

（1）同步阻塞IO（Blocking IO）

即传统的IO模型，在linux中默认情况下所有的socket都是阻塞模式。当用户进程调用了read()这个系统调用，内核就开始了IO的第一个阶段：准备数据。对于网络IO来说，很多时候数据在一开始还没有到达（比如，还没有收到一个完整的UDP包），这个时候内核就要等待足够的数据到来。而在用户进程这边，整个进程会被阻塞。当内核一直等到数据准备好了，它就会将数据从内核中拷贝到用户内存，然后内核返回结果，用户进程才解除阻塞的状态，重新运行起来；几乎所有的程序员第一次接触到的网络编程都是从listen()、read()、write() 等接口开始的，这些接口都是阻塞型的，一个简单的改进方案是在服务器端使用多线程（或多进程）。多线程（或多进程）的目的是让每个连接都拥有独立的线程（或进程），这样任何一个连接的阻塞都不会影响其他的连接。

（2）同步非阻塞IO（Non-blocking IO）

默认创建的socket都是阻塞的，同步非阻塞IO是在同步阻塞IO的基础上，将socket设置为NONBLOCK，这个可以使用ioctl()系统调用设置。这样做用户线程可以在发起IO请求后可以立即返回，如果该次读操作并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。整个IO请求的过程中，虽然用户线程每次发起IO请求后可以立即返回，但是为了等到数据，仍需要不断地轮询、重复请求，消耗了大量的CPU的资源。一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。

（3）IO多路复用（IO Multiplexing）

IO多路复用模型是建立在内核提供的多路分离函数select基础之上的，使用select函数可以避免同步非阻塞IO模型中轮询等待的问题，此外poll、epoll都是这种模型。在该种模式下，用户首先将需要进行IO操作的socket添加到select中，然后阻塞等待select系统调用返回。当数据到达时，socket被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行。从流程上来看，使用select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视socket，以及调用select函数的额外操作，效率更差。但是，使用select以后最大的优势是用户可以在一个线程内同时处理多个socket的IO请求。用户可以注册多个socket，然后不断地调用select读取被激活的socket，即可达到在同一个线程内同时处理多个IO请求的目的。而在同步阻塞模型中，必须通过多线程的方式才能达到这个目的。

（4）信号驱动IO（signal driven IO）

调用sigaltion系统调用，当内核中IO数据就绪时以SIGIO信号通知请求进程，请求进程再把数据从内核读入到用户空间，这一步是阻塞的。

（5）异步IO（Asynchronous IO）

即经典的Proactor设计模式，也称为异步非阻塞IO。“真正”的异步IO需要操作系统更强的支持。在IO多路复用模型中，事件循环将文件句柄的状态事件通知给用户线程，由用户线程自行读取数据、处理数据。而在异步IO模型中，当用户线程收到通知时，数据已经被内核读取完毕，并放在了用户线程指定的缓冲区内，内核在IO完成后通知用户线程直接使用即可。

相比于IO多路复用模型，信号驱动IO和异步IO并不十分常用，不少高性能并发服务程序使用IO多路复用模型+多线程任务处理的架构基本可以满足需求。况且目前操作系统对异步IO的支持并非特别完善，更多的是采用IO多路复用模型模拟异步IO的方式。

在这里我们把前三种做一个形象地类比：

• 阻塞IO, 给女神发一条短信, 说我来找你了, 然后就默默的一直等着女神下楼, 这个期间除了等待你不会做其他事情；
• 非阻塞IO, 给女神发短信, 如果不回, 接着再发, 一直发到女神下楼, 这个期间你除了发短信等待不会做其他事情；
• IO多路复用, 是找一个宿管大妈来帮你监视下楼的女生, 这个期间你可以做些其他的事情，例如可以顺便玩玩王者荣耀, 打篮球等等。IO复用又包括 select, poll, epoll 模式. 那么它们的区别是什么?

1. select大妈 每一个女生下楼, select大妈都不知道这个是不是你的女神, 她需要一个一个询问, 并且select大妈能力还有限, 最多一次帮你监视1024个妹子；

2. poll大妈 不限制盯着女生的数量, 只要是经过宿舍楼门口的女生, 都会帮你去问是不是你女神；

3. epoll大妈 不限制盯着女生的数量, 并且也不需要一个一个去问. 那么如何做呢? epoll大妈会为每个进宿舍楼的女生脸
   上贴上一个大字条,上面写上女生自己的名字, 只要女生下楼了, epoll大妈就知道这个是不是你女神了, 然后大妈再通知你；

总结：select和poll，不管三七二十一，把所有的文件描述符打包，再进行遍历操作，epoll打包后会有选择！选择有用的文件描述符进行操作！

5. select多路复用

select()函数允许进程指示内核等待多个事件(文件描述符)中的任何一个发生，并只在有一个或多个事件发生或经历一段指定时间后才唤醒它，然后接下来判断究竟是哪个文件描述符发生了事件并进行相应的处理。

基于select的I/O复用模型的是单进程执行可以为多个客户端服务，这样可以减少创建线程或进程所需要的CPU时间片或内存资源的开销；此外几乎所有的平台上都支持select()，其良好跨平台支持是它的另一个优点。当然它也有两个主要的缺点：

1. 每次调用 select()都需要把fd集合从用户态拷贝到内核态，之后内核需要遍历所有传递进来的fd，这时如果客户端fd很多
   时会导致系统开销很大；
2. 单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过setrlimit()、修改宏定义甚至重
   新编译内核等方式来提升这一限制，但是这样也会造成效率的降低；

6. poll多路复用

select()和poll()系统调用的本质一样，前者在BSD UNIX中引入的，后者在System V中引入的。poll()的机制与 select() 类似，与 select() 在本质上没有多大差别，管理多个描述符也是进行轮询，根据描述符的状态进行处理，但是 poll() 没有最大文件描述符数量的限制（但是数量过大后性能也是会下降）。poll() 和 select() 同样存在一个缺点就是，包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大。

poll函数的原型说明如下：

第一个参数用来指向一个struct pollfd类型的数组，每一个pollfd结构体指定了一个被监视的文件描述符，指示poll()监视多个文件描述符。每个结构体的events域是监视该文件描述符的事件掩码，由用户来设置这个域。revents域是文件描述符的操作结果事件掩码，内核在调用返回时设置这个域，events域中请求的任何事件都可能在revents域中返回。

第二个参数 nfds 指定数组中监听的元素个数；

第三个参数 timeout指定等待的毫秒数，无论I/O是否准备好，poll都会返回。timeout指定为负数值表示无限超时，使poll()
一直挂起直到一个指定事件发生；timeout为0指示poll调用立即返回并列出准备好I/O的文件描述符，但并不等待其它的事件。
这种情况下，poll()就像它的名字那样，一旦选举出来，立即返回。

例如，要同时监视一个文件描述符是否可读和可写，我们可以设置 events为POLLIN | POLLOUT。在poll返回时，我们可以检查revents中的标志，对应于文件描述符请求的events结构体。如果POLLIN事件被设置，则文件描述符可以被读取而不阻塞。如果POLLOUT被设置，则文件描述符可以写入而不导致阻塞。这些标志并不是互斥的：它们可能被同时设置，表示这个文件描述符的读取和写入操作都会正常返回而不阻塞。

7. epoll多路复用

在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。自Linux 2.6内核正式引入epoll以来，epoll已经成为了目前实现高性能网络服务器的必备技术，在大数据、高并发、集群等一些名词唱得火热之年代，select和poll的用武之地越来越有限，风头已经被epoll占尽。

select的缺点：

1. 单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量，但由于select采用轮询的方式扫描文件描述符，文件描述符数量越多，性能越差；
2. 内核 / 用户空间内存拷贝问题，select需要复制大量的句柄数据结构，产生巨大的开销；
3. select返回的是含有整个句柄的数组，应用程序需要遍历整个数组才能发现哪些句柄发生了事件；
4. select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次select调用还是会将这些文件描述符通知进程。

相比select模型，poll使用链表保存文件描述符，因此没有了监视文件数量的限制，但其他三个缺点依然存在。拿select模型为例，假设我们的服务器需要支持100万的并发连接，则在__FD_SETSIZE 为1024的情况下，则我们至少需要开辟1k个进程才能实现100万的并发连接。除了进程间上下文切换的时间消耗外，从内核/用户空间大量的无脑内存拷贝、数组轮询等，是系统难以承受的。因此，基于select模型的服务器程序，要达到10万级别的并发访问，是一个很难完成的任务。

epoll是Linux内核为处理大批量文件描述符而作了改进的poll，是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。另一点原因就是获取事件的时候，它无须遍历整个被侦听的描述符集，只要遍历那些被内核IO事件异步唤醒而加入Ready队列的描述符集合就行了。epoll除了提供select/poll那种IO事件的水平触发（Level Triggered）外，还提供了边缘触发（Edge Triggered），这就使得用户空间程序有可能缓存IO状态，减少epoll_wait/epoll_pwait的调用，提高应用程序效率。

LT（level triggered）是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表。

ET （edge-triggered）是高速工作方式，只支持non-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了（比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作（从而导致它再次变成未就绪），内核不会发送更多的通知（only once），不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认。

ET和LT的区别就在这里体现，LT事件不会丢弃，而是只要读buffer里面有数据可以让用户读，则不断的通知你。而ET则只在事
件发生之时通知。可以简单理解为LT是水平触发，而ET则为边缘触发。LT模式只要有事件未处理就会触发，而ET则只在高低电平变换时（即状态从1到0或者0到1）触发。

由于epoll的实现机制与select/poll机制完全不同，上面所说的 select的缺点在epoll上不复存在。设想一下如下场景：有100万个客户端同时与一个服务器进程保持着TCP连接。而每一时刻，通常只有几百上千个TCP连接是活跃的(事实上大部分场景都是这种情况)。如何实现这样的高并发？在select/poll时代，服务器进程每次都把这100万个连接告诉操作系统(从用户态复制句柄数据结构到内核态)，让操作系统内核去查询这些套接字上是否有事件发生，轮询完后，再将句柄数据复制到用户态，让服务器应用程序轮询处理已发生的网络事件，这一过程资源消耗较大，因此，select/poll一般只能处理几千的并发连接。

epoll的设计和实现与select完全不同。epoll通过在Linux内核中申请一个简易的文件系统，把原先的select/poll调用分成了3个部分：

1. 调用epoll_create()建立一个epoll对象(在epoll文件系统中为这个句柄对象分配资源)
2. 调用epoll_ctl向epoll对象中添加这100万个连接的套接字
3. 调用epoll_wait收集发生的事件的连接

如此一来，要实现上面说是的场景，只需要在进程启动时建立一个epoll对象，然后在需要的时候向这个epoll对象中添加或者
删除连接。同时，epoll_wait的效率也非常高，因为调用epoll_wait时，并没有一股脑的向操作系统复制这100万个连接的句柄数据，内核也不需要去遍历全部的连接。

1> 创建epoll实例：epoll_create()

#include <sys/epoll.h>
int epoll_create(int size)

系统调用epoll_create()创建了一个新的epoll实例，其对应的兴趣列表初始化为空。若成功返回文件描述符，若出错返回-1。参数size指定了我们想要通过epoll实例来检查的文件描述符个数。该参数并不是一个上限，而是告诉内核应该如何为内部数据结构划分初始大小。从Linux2.6.8版以来，size参数被忽略不用。

作为函数返回值，epoll_create()返回了代表新创建的epoll实例的文件描述符。这个文件描述符在其他几个epoll系统调用中用来表示epoll实例。当这个文件描述符不再需要时，应该通过close（）来关闭。当所有与epoll实例相关的文件描述符都被关闭时，实例被销毁，相关的资源都返还给系统。从2.6.27版内核以来，Linux支持了一个新的系统调用epoll_create1()。该系统调用执行的任务同epoll_create()一样，但是去掉了无用的参数size，并增加了一个可用来修改系统调用行为的flags参数。目前只支持一个flag标志：EPOLL_CLOEXEC，它使得内核在新的文件描述符上启动了执行即关闭标志。

2> 修改epoll的兴趣列表：epoll_ctl()

#include <sys/epoll.h>
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *ev）

系统调用epoll_ctl()能够修改由文件描述符epfd所代表的epoll实例中的兴趣列表。若成功返回0，若出错返回-1。

第一个参数epfd 是epoll_create()的返回值；

第二个参数op 用来指定需要执行的操作，它可以是如下几种值：

• EPOLL_CTL_ADD：将描述符fd添加到epoll实例中的兴趣列表中去。对于fd上我们感兴趣的事件，都指定在ev所指向的
  结构体中。如果我们试图向兴趣列表中添加一个已存在的文件描述符，epoll_ctl()将出现EEXIST错误；

• EPOLL_CTL_MOD：修改描述符上设定的事件，需要用到由ev所指向的结构体中的信息。如果我们试图修改不在兴趣列表
  中的文件描述符，epoll_ctl()将出现ENOENT错误；

• EPOLL_CTL_DEL：将文件描述符fd从epfd的兴趣列表中移除，该操作忽略参数ev。如果我们试图移除一个不在epfd的兴
  趣列表中的文件描述符，epoll_ctl()将出现ENOENT错误。关闭一个文件描述符会自动将其从所有的epoll实例的兴趣列表移除；

第三个参数fd 指明了要修改兴趣列表中的哪一个文件描述符的设定。该参数可以是代表管道、FIFO、套接字、POSIX消息队列、inotify实例、终端、设备，甚至是另一个epoll实例的文件描述符。但是，这里fd不能作为普通文件或目录的文件描述符；

第四个参数ev 是指向结构体epoll_event的指针，结构体的定义如下：

参数ev为文件描述符fd所做的设置（epoll_event）如下：

• events字段是一个位掩码，它指定了我们为待检查的描述符fd上所感兴趣的事件集合；
• data字段是一个联合体，当描述符fd稍后称为就绪态时，联合的成员可用来指定传回给调用进程的信息；

3> 事件等待：epoll_wait()

#include <sys/epoll.h>
int epoll_wait(int epfd, struct epoll_event *evlist, int maxevents, int timeout)

系统调用epoll_wait()返回epoll实例中处于就绪态的文件描述符信息，单个epoll_wait()调用能够返回多个就绪态文件描述符的信息。调用成功后epoll_wait()返回数组evlist中的元素个数，如果在timeout超时间隔内没有任何文件描述符处于就绪态的话就返回0，出错时返回-1并在errno中设定错误码以表示错误原因。

第一个参数epfd是epoll_create()的返回值；

第二个参数evlist所指向的结构体数组中返回的是有关就绪态文件描述符的信息，数组evlist的空间由调用者负责申请；

第三个参数maxevents指定所evlist数组里包含的元素个数；

第四个参数timeout用来确定epoll_wait()的阻塞行为，有如下几种：

• 如果timeout等于-1，调用将一直阻塞，直到兴趣列表中的文件描述符上有事件产生或者直到捕获到一个信号为止。
• 如果timeout等于0，执行一次非阻塞式地检查，看兴趣列表中的描述符上产生了哪个事件。
• 如果timeout大于0，调用将阻塞至多timeout毫秒，直到文件描述符上有事件发生，或者直到捕获到一个信号为止。

数组evlist中，每个元素返回的都是单个就绪态文件描述符的信息。events字段返回了在该描述符上已经发生的事件掩码。data字段返回的是我们在描述符上使用epoll_ctl()注册感兴趣的事件时在ev.data中所指定的值。注意，data字段是唯一可获知同这个事件相关的文件描述符的途径。因此，当我们调用epoll_ctl()将文件描述符添加到感兴趣列表中时，应该要么将ev.date.fd设为文件描述符号，要么将ev.date.ptr设为指向包含文件描述符号的结构体。

默认情况下，一旦通过epoll_ctl()的EPOLL_CTL_ADD操作将文件描述符添加到epoll实例的兴趣列表中后，它会保持激活状态（即，之后对epoll_wait()的调用会在描述符处于就绪态时通知我们）直到我们显示地通过epoll_ctl()的EPOLL_CTL_DEL操作将
其从列表中移除。如果我们希望在某个特定的文件描述符上只得到一次通知，那么可以在传给epoll_ctl()的ev.events中指定EPOLLONESHOT标志。如果指定了这个标志，那么在下一个epoll_wait()调用通知我们对应的文件描述符处于就绪态之后，这
个描述符就会在兴趣列表中被标记为非激活态，之后的epoll_wait()调用都不会再通知我们有关这个描述符的状态了。如果需要，我们可以稍后用过调用epoll_ctl()的EPOLL_CTL_MOD操作重新激活对这个文件描述符的检查。

下面是使用epoll()多路复用实现的服务器端示例代码：