示意图如下：
这里select监听的socket都是non-blocking的，所以在do_read() do_write()中对返回为eagain/wsaewouldblock都做了处理。
从代码中可以看出使用select返回后，仍然需要轮训再检测每个socket的状态（读、写），这样的轮训检测在大量连接下也是效率不高的。因为当需要探测的句柄值较大时，select () 接口本身需要消耗大量时间去轮询各个句柄。
很多操作系统提供了更为高效的接口，如 linux 提供 了 epoll，bsd 提供了 kqueue，solaris 提供了 /dev/poll …。如果需要实现更高效的服务器程序，类似 epoll 这样的接口更被推荐。遗憾的是不同的操作系统特供的 epoll 接口有很大差异，所以使用类似于 epoll 的接口实现具有较好跨平台能力的服务器会比较困难。
5、使用事件驱动库libevent的服务器模型
libevent 是一种高性能事件循环/事件驱动库。
为了实际处理每个请求，libevent 库提供一种事件机制，它作为底层网络后端的包装器。事件系统让为连接添加处理函数变得非常简便，同时降低了底层io复杂性。这是 libevent 系统的核心。
创建 libevent 服务器的基本方法是，注册当发生某一操作（比如接受来自客户端的连接）时应该执行的函数，然后调用主事件循环 event_dispatch()。执行过程的控制现在由 libevent 系统处理。注册事件和将调用的函数之后，事件系统开始自治；在应用程序运行时，可以在事件队列中添加（注册）或 删除（取消注册）事件。事件注册非常方便，可以通过它添加新事件以处理新打开的连接，从而构建灵活的网络处理系统。
使用libevent实现的一个回显服务器如下：
6、信号驱动io模型（signal-driven io）
使用信号，让内核在描述符就绪时发送sigio信号通知应用程序，称这种模型为信号驱动式i/o（signal-driven i/o）。
图示如下：
首先开启套接字的信号驱动式i/o功能，并通过sigaction系统调用安装一个信号处理函数。该系统调用将立即返回，我们的进程继续工作，也就是说进程没有被阻塞。当数据报准备好读取时，内核就为该进程产生一个sigio信号。随后就可以在信号处理函数中调用recvfrom读取数据报，并通知主循环数据已经准备好待处理，也可以立即通知主循环，让它读取数据报。
无论如何处理sigio信号，这种模型的优势在于等待数据报到达期间进程不被阻塞。主循环可以继续执行 ，只要等到来自信号处理函数的通知：既可以是数据已准备好被处理，也可以是数据报已准备好被读取。
7、异步io模型（asynchronous io）
异步i/o（asynchronous i/o）由posix规范定义。演变成当前posix规范的各种早起标准所定义的实时函数中存在的差异已经取得一致。一般地说，这些函数的工作机制是：告知内核启动某个操作，并让内核在整个操作（包括将数据从内核复制到我们自己的缓冲区）完成后通知我们。这种模型与前一节介绍的信号驱动模型的主要区别在于：信号驱动式i/o是由内核通知我们何时可以启动一个i/o操作，而异步i/o模型是由内核通知我们i/o操作何时完成。
我们调用aio_read函数（posix异步i/o函数以aio_或lio_开头），给内核传递描述符、缓冲区指针、缓冲区大小（与read相同的三个参数）和文件偏移（与lseek类似），并告诉内核当整个操作完成时如何通知我们。该系统调用立即返回，并且在等待i/o完成期间，我们的进程不被阻塞。本例子中我们假设要求内核在操作完成时产生某个信号，该信号直到数据已复制到应用进程缓冲区才产生，这一点不同于信号驱动i/o模型。
参考：
《unix网络编程》
使用 libevent 和 libev 提高网络应用性能：http://www.ibm.com/developerworks/cn/aix/library/au-libev/
使用异步 i/o 大大提高应用程序的性能：https://www.ibm.com/developerworks/cn/linux/l-async/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。http://www.cnblogs.com/luxiaoxun/p/3691800.html