epoll学习笔记

zl_linux

“如果对应的缓冲区本身已经有了N字节的数据,而只取出了小于N字节的数据,那么残存的数据不会造成状态发生变化.”
我测了一下,上述情况epoll_wait下次仍会返回该sockfd的

cookis

我也发现有问题..我在接收的地方sleep(10).结果epoll_wait 马上就又检测到可读事件. 倒致多个线程全都是去接收了..

vbs100

原帖由 marxn 于 2008-5-22 21:42 发表


recv 返回值小于请求的长度时说明缓冲区已经没有可读数据. 但再读不一定会触发EAGAIN.有可能返回0表示TCP连接已被关闭。

这个没有必要的，没有数据就不用再读了，tcp断开的时候会触发EPOLLHUP事件

原帖由 UnixStudier 于 2008-5-23 09:40 发表
converse:"
1)对于监听可读事件时,如果是socket是监听socket,那么当有新的主动连接到来为状态发生变化;对一般的socket而言,协议栈中相应的缓冲区有新的数据为状态发生变化.但是,如果在一个时间同时接收了N个连 ...

在ET模式下 accetp应该一直运行到EAGAIN错误 这样就可以了

xinglp

原帖由 vbs100 于 2008-12-2 19:38 发表
这个没有必要的，没有数据就不用再读了，tcp断开的时候会触发EPOLLHUP事件
在ET模式下 accetp应该一直运行到EAGAIN错误 这样就可以了

TCP断开大部分时候触发的是EPOLLIN吧，recv得0

vbs100

Q9     Do I need to continuously read/write a file descriptor until EAGAIN when using the EPOLLET flag (edge-trig-
              gered behavior) ?

       A9     No  you  don't.   Receiving  an event from epoll_wait(2) should suggest to you that such file descriptor is
              ready for the requested I/O operation.  You have simply to consider it ready until  you  will  receive  the
              next  EAGAIN.   When  and how you will use such file descriptor is entirely up to you.  Also, the condition
              that the read/write I/O space is exhausted can be detected by checking the amount of data read from / writ-
              ten  to the target file descriptor.  For example, if you call read(2) by asking to read a certain amount of
              data and read(2) returns a lower number of bytes, you can be sure of having exhausted the  read  I/O  space
              for such file descriptor.  The same is true when writing using write(2).