客户端断开连接是由文件描述符上的EOF条件发出的.系统认为EOF是文件描述符为可读"状态.但是，当然，无法读取EOF条件.这是循环的来源. epoll的行为就像始终可读的断开连接的客户端的文件描述符一样.通过检查read何时返回读取的0个字节，您可以检测到您处于EOF条件.

A client disconnection is signalled by an EOF condition on the file descriptor. The system considers EOF to be a state in which the file descriptor is 'readable'. But, of course, the EOF condition cannot be read. This is the source of your looping. epoll is acting like the file descriptor for the disconnected client is always readable. You can detect that you have an EOF condition by checking when read returns 0 bytes read.

处理EOF条件的唯一方法是以某种方式close文件描述符. ，shutdown(sockfd, SHUT_RDWR)或close(sockfd);可能取决于事物的流动方式.

The only way to deal with an EOF condition is to close the file descriptor in some way. Depending on exactly how the flow of things go, this could be with shutdown(sockfd, SHUT_RD), shutdown(sockfd, SHUT_RDWR) or close(sockfd);.

除非您知道您需要 shutdown(2) 出于任何原因致电，我建议您使用close.当然，您应该记得在close之前告诉epoll不再需要文件描述符.我不确定如果不这样做会发生什么，但是一种可能性是epoll会出错.另一个是epoll将神秘地开始报告具有相同数值的新文件描述符的事件，然后再将其添加到epoll应该关心的列表中.

Unless you know that you need the shutdown(2) call for whatever reason, I would recommend you use close. Of course, you should remember to tell epoll that the file descriptor is no longer of interest before you close. I'm not sure what will happen if you don't, but one possibility is that epoll will error. Another is that epoll will mysteriously begin reporting events for a new file descriptor that has the same numeric value before you add it to the list epoll should care about.