【Unix环境编程】select、poll、epoll机制的联系与区别

标签：

　　在linux设计并发网络程序，主要有如下几种模型：Apache模型（Process Per Connection, PPC)、TPC（Thread Per Connection)模型，select机制、poll机制以及epoll。

1.  PPC/TPC模型

　　这两种模型思想类似，每一个新的链接就用一个线程或者进程处理。PPC使用使用进程、TPC使用线程。缺点是连接多了以后，这么多进程和线程的切换非常大。因此这类模型的能接受的最大连接数不会太高，一般几百个左右。

2.  select机制

　　PPC/TPC模型每个连接一个线程的开销太大。select就是使用一个线程/进程处理多个连接的机制。select最早于1983年出现在4.2BSD中，它通过一个select()系统调用来监视多个文件描述符的数组，当select()返回后，该数组中就绪的文件描述符便会被内核修改标志位，使得进程可以获得这些文件描述符从而进行后续的读写操作。注意，进程/线程在调用select等待描述符准备好，以及当一个描述符准备好然后从这个描述符读/写数据时一直是被阻塞的。所以select机制属于同步I/O。

　　select机制的缺点：

　　1.  最大并发连接数，因为一个进程所打开的FD（文件描述符）是有限的。由FD_SETSIZE设置，默认值是1024/2048。在Linux上一般为1024，不过可以通过修改宏定义甚至重新编译内核的方式提升这一限制。因此select的最大并发连接数就被相应限制了。

　　2.  效率问题。select每次调用都会线性扫描全部的FD集合，这样效率就会线性下降。

　　3.  如何让内核把 FD 消息通知给用户空间呢？在这个问题上 select 采取了内存拷贝方法。即包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大。

3.  poll机制

　　poll类似于select，只是程序接口有所不同。与select不同，poll不是为每个条件（可读性、可写性和异常条件）构造一个描述符集，而是构造一个pollfd结构的数组，每个数组元素指定一个描述符编号以及我们对该描述符感兴趣的条件。

　　poll并没有改进select的缺点。

4.  epoll机制

　　直到Linux2.6才出现了由内核直接支持的实现方法，那就是epoll，它几乎具备了之前所说的一切优点，被公认为Linux2.6下性能最好的多路I/O就绪通知方法。

　　epoll可以同时支持水平触发和边缘触发（Edge Triggered，只告诉进程哪些文件描述符刚刚变为就绪状态，它只说一遍，如果我们没有采取行动，那么它将不会再次告知，这种方式称为边缘触发），理论上边缘触发的性能要更高一些，但是代码实现相当复杂。

　　epoll同样只告知那些就绪的文件描述符，而且当我们调用epoll_wait()获得就绪文件描述符时，返回的不是实际的描述符，而是一个代表 就绪描述符数量的值，你只需要去epoll指定的一个数组中依次取得相应数量的文件描述符即可，这里也使用了内存映射（mmap）技术，这样便彻底省掉了这些文件描述符在系统调用时复制的开销。

　　另一个本质的改进在于epoll采用基于事件的就绪通知方式。在select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描 述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调 机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知

 　　epoll有2种工作方式：LT和ET：

参考资料：

　　1.  http://blog.csdn.net/orz415678659/article/details/8958415

　　2.  http://blog.csdn.net/tianmohust/article/details/6677985

　　3.  http://blog.csdn.net/xiajun07061225/article/details/9250579

　　4.  http://www.cricode.com/3499.html

【Unix环境编程】select、poll、epoll机制的联系与区别

标签：

原文地址：http://www.cnblogs.com/vincently/p/4758758.html