epoll 边缘触发模式的问题

cookis

EN..我觉得返回值小于请求长度就可以当做一次状态的改变了..

不过我想不出在nonblock 模式下. 水平触发和边缘触发有什么区别了.
我在水平模式下照样可以使用边缘触发模式的接收方式..一次将缓冲区内的数据收完.
而且还少了一次recv调用.

相比.水平反而比边缘要高效一些.

timespace

EN..我觉得返回值小于请求长度就可以当做一次状态的改变了..

man epoll也提到这一点，POSIX.1采用BSD处理被中断系统调用的方法，当read被中断也可能返回部分数据，Linux也是这样实现的.所以ET时，唯有read或write到EAGAIN时才算真正事件改变

不过我想不出在nonblock 模式下. 水平触发和边缘触发有什么区别了.
我在水平模式下照样可以使用边缘触发模式的接收方式..一次将缓冲区内的数据收完.
而且还少了一次recv调用.

相比.水平反而比边缘要高效一些.

这不见得吧。实际程序总是epoll_wait后，再recv，不可能一直recv下去，一个线程处理一个连接还好说，最多CPU利用率高点儿，但同时处理多连接时，会造成其它连接starvation。
man epoll提到ET时程序没必要一直recv到EAGAIN，程序行为可以自己控制，比如设定一个接收长度或接收超时，然后处理其它流程，此时可以设置个可读标记，说明此连接处于可读状态，下次在接受数据时就无需epoll_wait了，程序也可以少epoll_wait且内核也个少监控的FD事件，直read到EAGAIN，内核才会再次监控对应FD的EPOLLIN，这对于监控大量连接是由很有好处的；而LT每次不管能否read EGAIN都要epoll_wait，内核始终都会通知FD的EPOLLIN，这对于始终处于可读状态的连接是个浪费（前面已经说过，有意义的程序不一定总是recv到EGAIN，要设定合理的控制参数）

chenzhanyiczy

原帖由 marxn 于 2008-11-7 18:17 发表
这种状况只出现在客户端发出一个包含数据的TCP segment之后没有等服务器ACK到来就立即发送FIN的情形。这就是为什么客户端发送完毕数据之后sleep一段时间就能够正常终止连接的原因。所以如果要建立一个健壮的服务 ...

服务器ACK已经是发送了的，它是tcp栈实现的。这里问题应该在于，数据和fin困在一起了

另外，我觉得这个不是epoll的bug,就像我上面说的，epoll不一定要读到EGAIN的时候才认为是没有数据可读了

cookis

man epoll提到ET时程序没必要一直recv到EAGAIN，程序行为可以自己控制，比如设定一个接收长度或接收超时，然后处理其它流程，此时可以设置个可读标记，说明此连接处于可读状态，下次在接受数据时就无需epoll_wait了，程序也可以少epoll_wait且内核也个少监控的FD事件，直 read到EAGAIN，内核才会再次监控对应FD的EPOLLIN，这对于监控大量连接是由很有好处的；

你用LT模式也采用这样做法. 结果是一样的. 当然前提是连接全部是nonblock, 这样绝对不会导致其他连接处理饥渴状态, 而且LT模式如果recv返回长度小于请求长度. 就不再触发新的事件了. 但ET还需要再调用一次recv直到errno == EAGAIN. 我想它们之间的区别就在这儿了.(至少在表面上是这样的)

chenzhanyiczy

看来大家的意见都不一样

wishel

理解lt和et的语义后问题就很简单。
lt模式跟select有一样的语义。就是如果可读就触发。比如某管道原来为空，如果有一个进程写入2k数据，就会触发。如果处理进程读取1k数据，下次轮询时继续触发。
而et模式有不同的语义。只有当从不可读变为可读时才触发。上面那种情况，还有1k可读，所以不会触发。当继续读，直到返回EAGAIN时，变为不可读，如果再次变为可读就触发。
为什么说et效率高呢，它默认fd是一直可读的。可以一直读直到EAGAIN发生。也就是说它只监控状态的变化。
什么时候能体现这种效率呢？当环境中存在大量慢速连接的时候。因为处理很慢，lt会不停的触发event，但是et就不会。

chenzhanyiczy

A9: Do I need to continuously read/write an fd until EAGAIN when using the EPOLLET flag ( Edge Triggered behaviour ) ?

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/write from/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 to have exhausted the read I/O space for such file descriptor. Same is valid when writing using the write(2) function.


对于上面那段man，我不是很理解,这段话的含义到底是说什么？想表达什么意思？好像感觉与ET的模式有点意义上的不和

[ 本帖最后由 chenzhanyiczy 于 2008-11-9 01:26 编辑 ]

cugb_cat

EAGIN
楼主没理解ET

wishel

原帖由 chenzhanyiczy 于 2008-11-9 01:25 发表
A9: Do I need to continuously read/write an fd until EAGAIN when using the EPOLLET flag ( Edge Triggered behaviour ) ?

A9: No you don't. Receiving an event from epoll_wait(2) should suggest  ...

lt模式下，默认不可读，只有epoll通知你可读才是可读，否则不可读。
et模式下，默认可读。你可以随便读，直到发生EAGAIN。可读时读和不读，怎么读都由你自己决定，中间epoll不管。
EAGAIN后不可读了，等到再次可读，epoll会再通知一次。

flw

注意语义就好了。