Dev_Poll_Reactor使用中要注意的一个小陷阱

wesom

最近调试ACE6.0.0版本中Dev_Poll_Reactor的性能测试中发现了一个程序中的bug。
现象：1000客户端连接 - 100ms发一次 - 10k包大小 - 服务器A，A转发到服务器B，
          运行几分钟后，A与B间连接的读写事件已无法响应，状态为established。
          同样的程序改为Select_Reactor模型运行起来很正常。
问题很蹊跷，我随即看看下Poll_Reactor的实现，找到了原因。
主要是Client_Handle中handle_output的实现有点问题，因为Poll_Reactor的epoll采取的是
EPOLLONESHOT的方式，监听完fd的一次事件后得再次添加fd，所以reactor回调完handle_*后根据返回值来判断继续注册之前感兴趣的事件还是remove_handle(),如果之前的handle_*返回-1，会丢失所有已注册过的事件。而我的程序在调度WRITE_MASK事件时，通过返回-1而在handle_close中做处理，这样的方式在Select_Reactor中是没问题的，但是在Poll_Reactor中就是个杯具啊。
于是改成schedule/cancel方式，测试到6000连接的发包，一切正常。
感觉采用oneshot的方式对性能有不少影响，应该是ace的设计者只是为了在多线程下实现更方便，而不想实现类似TP_EPoll的Epoll版lead/flower。

ztenv

又能不掉进这个陷井了

jonathanliu2004

什么是schedule/cancel方式？ 如何设置schedule/cancel方式还是lead/flower方式？