我们首先需要知道select，poll，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的。
select的基本用法：http://blog.csdn.net/nk_test/article/details/49256129
poll的基本用法：http://blog.csdn.net/nk_test/article/details/49283325
epoll的基本用法：http://blog.csdn.net/nk_test/article/details/49331717
接下来我们探讨如何正确使用non-blocking I/O Multiplexing + poll/epoll。
先来说几个常见的问题：
1.SIGPIPE信号的产生和处理
如果客户端使用close关闭套接字，而服务器端调用了一次write，服务器会接收一个RST segment（TCP传输层）; 如果服务器再次调用write，这个时候就会产生SIGPIPE信号，如果不忽略，就会默认退出程序，显然是不满足服务器的高可用性。可以在程序中直接忽略掉，如 signal(SIGPIPE, SIG_IGN)。
2.TIME_WAIT 状态对 服务器的影响
应尽可能避免在服务端出现TIME_WAIT状态。如果服务器主动断开连接（先于client调用close），服务端就会进入TIME_WAIT状态，内核会hold住一些资源，大大降低服务器的并发能力。解决方法：协议设计上，应该让客户端主动断开连接，这样就可以把TIME_WAIT状态分散到大量的客户端。如果客户端不活跃了，一些恶意的客户端不断开连接，这样就会占用服务器端的连接资源。所以服务端也要有机制来踢掉不活跃的连接。
3.新的accept4系统调用
多了flags参数，可以设置以下两个标志：
int accept4(int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags);
SOCK_NONBLOCK Set the O_NONBLOCK file status flag on the new open file description. Using this flag saves extra calls to fcntl(2) to achieve the same result.
SOCK_CLOEXEC Set the close-on-exec (FD_CLOEXEC) flag on the new file descriptor. See the description of the O_CLOEXEC flag in open(2) for reasons why this may be useful.
进程被替换时，文件描述符是关闭的状态，用来设置返回的已连接套接字，也可以使用fcntl设置，但是效率稍微低一些。
4.accept(2)返回EMFILE的处理（文件描述符已经用完）
（1）调高进程文件描述符数目
（2）死等
（3）退出程序
（4）关闭监听套接字。那什么时候重新打开呢？
（5）如果是epoll模型，可以改用edge trigger。问题是如果漏掉了一次accept(2)，程序再也不会收到新连接（没有状态变化）
（6）准备一个空闲的文件描述符。遇到这种情况，先关闭这个空闲文件，获得一个文件描述符名额;再accept(2)拿到socket连接的文件描述符；随后立刻close(2)，这样就优雅地断开了与客户端的连接；最后重新打开空闲文件，把“坑”填上，以备再次出现这种情况时使用。
int idlefd = open("/dev/null", O_RDONLY | O_CLOEXEC);
connfd = accept4(listenfd, (struct sockaddr *)&peeraddr,
&peerlen, SOCK_NONBLOCK | SOCK_CLOEXEC);
/* if (connfd == -1)
ERR_EXIT("accept4");
*/
if (connfd == -1)
{
if (errno == EMFILE)
{
close(idlefd);
idlefd = accept(listenfd, NULL, NULL);
close(idlefd);
idlefd = open("/dev/null", O_RDONLY | O_CLOEXEC);
continue;
}
else
ERR_EXIT("accept4");
}
（一）poll的处理流程和需要注意的问题
需要注意的问题及其处理方法：
(1) 粘包问题：read 可能一次并没有把connfd 所对应的接收缓冲区（内核）的数据都读完，那么connfd下次仍然是活跃的。我们应该将读到的数据保存在connfd的应用层缓冲区（char buf[1024]），并处理好消息的边界。
(2)write应答的数据量较大的情况下，可能一次并不能把所有的数据发送到内核的缓冲区，所以应该有一个应用层的缓冲区，将未发送完的数据添加到应用层发送缓冲区。
(3)关注connfd 的POLLOUT 事件的时机。POLLOUT事件到来，则取出应用层发送缓冲区数据发送write，如果应用层发送缓冲区数据发送完毕，则取消关注POLLOUT事件。POLLOUT 事件触发条件：connfd的发送缓冲区（内核）不满（可以容纳数据）。
注：connfd 的接收缓冲区（内核）数据被接收后会被清空，当发出数据段后接收到对方的ACK段后，发送缓冲区（内核）数据段会被清空。write只是将应用层发送缓冲区数据拷贝到connfd 对应的内核发送缓冲区就返回；read 只是从connfd对应的内核接收缓冲区数据拷贝到应用层接收缓冲区就返回。
（二）epoll的处理流程和需要注意的问题 电平触发模式：
基本处理流程和poll十分相似。注意epoll_wait返回的都是活跃的，不用遍历，直接处理即可。write返回成功只是说明将数据拷贝至内核缓冲区。 EPOLLIN 事件
内核中的某个socket接收缓冲区 为空 低电平 内核中的某个socket接收缓冲区 不为空 高电平
EPOLLOUT 事件
内核中的某个socket发送缓冲区 不满 高电平 内核中的某个socket发送缓冲区 满 低电平
注：只要第一次write没写完整，则下次调用write直接把数据添加到应用层缓冲区OutBuffer，等待EPOLLOUT事件。 边沿触发模式：
缺点：
可能产生漏连接accept的bug，很难处理；
文件描述符达到上限后，一直处于高电平，不会再触发了。处理起来也比较麻烦。
推荐epoll使用LT模式的原因： 其中一个是与poll兼容； LT（水平）模式不会发生漏掉事件的BUG，但POLLOUT事件不能一开始就关注，否则会出现busy loop(即暂时还没有数据需要写入，但一旦连接建立，内核发送缓冲区为空会一直触发POLLOUT事件)，而应该在write无法完全写入内核缓冲区的时候才关注，将未写入内核缓冲区的数据添加到应用层output buffer，直到应用层output buffer写完，停止关注POLLOUT事件。 读写的时候不必等候EAGAIN，可以节省系统调用次数，降低延迟。（注：如果用ET模式，读的时候读到EAGAIN,写的时候直到output buffer写完或者写到EAGAIN）
注：在使用 ET 模式时，可以写得更严谨，即将 listenfd 设置为非阻塞，如果accpet 调用有返回，除了建立当前这个连接外，不能马上就回到 epoll_wait ，还需要继续循环accpet，直到返回-1 且errno == EAGAIN 才退出。代码示例如下：
if(ev.events & EPOLLIN)
{
do
{
struct sockaddr_in stSockAddr;
socklen_t iSockAddrSize = sizeof(sockaddr_in);
int iRetCode = accept(listenfd, (struct sockaddr *) &stSockAddr, iSockAddrSize);
if (iRetCode > 0)
{
// ...建立连接
// 添加事件关注
}
else
{
//直到发生EAGAIN才不继续accept
if(errno == EAGAIN)
{
break;
}
}
}
while(true);
// ... 其他 EPOLLIN 事件
}
（三）三者各方面的比较
select：fd_set有文件描述符个数的限制；另外每次都要复制到内核空间，扫描O(N)的复杂度。要遍历所有的文件描述符去判断是否发生了事件。
poll：也是拷贝和轮询。拷贝至内核中的链表，没有最大连接数的限制。
epoll：使用共享内存（mmap）减少复制开销，存放感兴趣的套接字，都是在内核态操作的，采用事件通知的回调机制。
注意：并不是在任何条件下epoll的效率都是最高的，要根据实际的应用情况来判断使用哪种I/O。
如果已连接套接字数目不太大并且这些套接字一直处于活跃的状态，那么不停地调用callback函数可能会造成低效率，也就是说低于一次性遍历，此时epoll的效率就可能低于select和poll。