http://www.ccvita.com/515.html

在一个非阻塞(fcntl)的socket上调用read/write函数, 返回EAGAIN或者EWOULDBLOCK(注: EAGAIN就是EWOULDBLOCK)

这个错误表示资源暂时不够, 可能read时, 读缓冲区没有数据, 或者, write时,写缓冲区满了.  (此处读写缓冲区指的是socket的缓冲区，而不是read或write调用形参中的buffer)

遇到这种情况, 如果是阻塞socket, read/write就要阻塞掉.而如果是非阻塞socket, read/write立即返回-1, 同 时errno设置为EAGAIN.所以, 对于阻塞socket, read/write返回-1代表网络出错了.但对于非阻塞socket, read/write返回-1不一定网络真的出错了.可能是Resource temporarily unavailable. 这时你应该再试, 直到Resource available.

综上, 对于non-blocking的socket,  正确的读写操作为:

读: 忽略掉errno = EAGAIN的错误, 下次继续读　

写: 忽略掉errno = EAGAIN的错误, 下次继续写　

对于select和epoll的LT模式, 这种读写方式是没有问题的. 但对于epoll的ET模式, 这种方式还有漏洞.

epoll的两种模式 LT 和 ET

二者的差异在于 level-trigger 模式下只要某个 socket 处于 readable/writable 状态，无论什么时候调用epoll_wait 都会返回该 socket；而 edge-trigger 模式下只有某个 socket 从 unreadable 变为 readable 或从unwritable 变为 writable 时，epoll_wait 才会返回该 socket。

从socket读数据:

往socket写数据：

所以, 在epoll的ET模式下, 正确的读写方式为:

读: 只要可读, 就一直读, 直到返回0, 或者 errno = EAGAIN

写: 只要可写, 就一直写, 直到数据发送完, 或者 errno = EAGAIN

正确的读：

n = 0;
while ((nread = read(fd, buf + n, BUFSIZ-1)) > 0) {  n += nread;
}
if (nread == -1 && errno != EAGAIN) {  perror("read error");
}  

正确的写：

int nwrite, data_size = strlen(buf);
n = data_size;
while (n > 0) {  nwrite = write(fd, buf + data_size - n, n);  if (nwrite < n) {  if (nwrite == -1 && errno != EAGAIN) {  perror("write error");  }  break;  }  n -= nwrite;
}  

我的理解：LT模式下，read、write不需要while循环了，即使这次系统调用没有处理完所有数据，下次调用epoll_wait时也会返回该就绪事件（上述write相关代码感觉不对）

正确的accept，accept 要考虑 2 个问题

(1) 阻塞模式 accept 存在的问题

accept每次都是从已经完成三次握手的tcp队列中取出一个连接

考虑这种情况： TCP 连接被客户端夭折，即在服务器调用 accept 之前，客户端主动发送 RST 终止连接，导致刚刚建立的连接从就绪队列中移出，如果套接字被设置成阻塞模式，服务器就会一直阻塞在 accept 调用上(即此时没有客户端连接给accept)，直到其他某个客户建立一个新的连接为止（即accept接受新的连接，返回）。但是在此期间，服务器单纯地阻塞在accept 调用上，就绪队列中的其他描述符都得不到处理(我的理解：其他fd读写事件就绪但得不到处理).

解决办法是把监听套接口设置为非阻塞，当客户在服务器调用 accept 之前中止某个连接时，accept 调用可以立即返回 -1， 这时源自 Berkeley 的实现会在内核中处理该事件，并不会将该事件通知给 epoll，而其他实现把 errno 设置为 ECONNABORTED 或者 EPROTO 错误，我们应该忽略这两个错误。

(2) ET 模式下 accept 存在的问题

考虑这种情况：多个连接同时到达，服务器的 TCP 就绪队列瞬间积累多个就绪连接，由于是边缘触发模式，epoll 只会通知一次，accept 只处理一个连接，导致 TCP 就绪队列中剩下的连接都得不到处理。

解决办法是用 while 循环抱住 accept 调用，处理完 TCP 就绪队列中的所有连接后再退出循环。如何知道是否处理完就绪队列中的所有连接呢？ accept  返回 -1 并且 errno 设置为 EAGAIN 就表示所有连接都处理完。

综合以上两种情况，服务器应该使用非阻塞地 accept， accept 在 ET 模式下 的正确使用方式为：

while ((conn_sock = accept(listenfd,(struct sockaddr *) &remote,   (size_t *)&addrlen)) > 0) {  handle_client(conn_sock);
}
if (conn_sock == -1) {  if (errno != EAGAIN && errno != ECONNABORTED   && errno != EPROTO && errno != EINTR)   perror("accept");
}  

我的总结：当epoll在ET模式下，read、write、accept操作都在while循环中执行，使得所有数据或者连接都处理完，因为ET模式下，epoll_wait只返回一次

一道腾讯后台开发的面试题

使用Linux epoll模型，水平触发模式，当socket可写时，会不停的触发 socket 可写的事件，如何处理？

第一种最普遍的方式：

需要向 socket 写数据的时候才把 socket 加入 epoll ，等待可写事件。接受到可写事件后，调用 write 或者 send 发送数据。当所有数据都写完后，把 socket 移出 epoll。

这种方式的缺点是，即使发送很少的数据，也要把 socket 加入 epoll，写完后在移出 epoll，有一定操作代价。

一种改进的方式：

开始不把 socket 加入 epoll，需要向 socket 写数据的时候，直接调用 write 或者 send 发送数据。如果返回 EAGAIN，把 socket 加入 epoll，在 epoll 的驱动下写数据，全部数据发送完毕后，再移出 epoll。

这种方式的优点是：数据不多的时候可以避免 epoll 的事件处理，提高效率。