请教大家关于ACE_Dev_Poll_Reactor的问题

wishel

。。。

[ 本帖最后由 wishel 于 2009-11-11 15:54 编辑 ]

wishel

原帖由 modern 于 2009-11-10 14:25 发表
我没有看到有使用EPOLLONESHOT禁用Epoll对特定文件描述符的监听。

EPOLLONESHOT的意思不是禁用Epoll对特定文件描述符的监听，而是指 一次性使用
即触发一次后就从epoll注册的监听集合中去掉，想要再次监听就要再次add
man epoll有解释，主要是防止事件处理过程中又产生新的事件通知，这样有更好的性能。

wishel

再仔细想了下，以前对oneshot的理解有误，实际上oneshot是比et更加严格。比如读socket的时候，在对方不再发送时，et是一次性的，但是如果有新数据到来，即使本次没有读完，et还是会触发。而onshot是绝对的一次性。
所以ACE_DEV_POLL_REACTOR虽然用了ONESHOT，但是在HANDLE_*后又调用了RESUME_HANDLER，自动ADD了回去。所以它是LT语义。

其实ET模式就是对用户行为的一种强制。如果说ET模式高效，LT模式一样可以达到这种高效（FD为NONBLOCK模式），就是用户每次必须一直处理到EAGAIN才结束。如果用户不这样做，
1）LT模式时，下次WAIT继续触发通知。低效。
2）ET模式时，下次WAIT不会触发通知，线程永久BLOCK。
这种方式，$ACE_ROOT/TESTS/DEV_POLL_REACTOR_TEST.CPP中称为SPECULATIVE READ/WRITE，如果用户采取这种模式，两者具有相同的表现和效率。

由以上理解，其实ACE_DEV_POLL_REACTOR没必要实现ET，用户追求ET的高效的话，可以在NONBLOCK FD上采用SPECULATIVE READ/WRITE模式。

我把前面的楼改了。

[ 本帖最后由 wishel 于 2009-11-11 15:55 编辑 ]

wishel

在ACE_Dev_Poll_Reactor::dispatch_io_event中找到了这段：

      /* When using sys_epoll, we can attach arbitrary user
         data to the descriptor, so it can be delivered when
         activity is detected. Perhaps we should store event
         HANDLER TOGETHER WITH DESCRIPTOR, INSTEAD OF LOOKING
         it up in a repository ? Could it boost performance ?
      */

可惜好的想法提出来后，这么多版本过去了还是没有实现。奇怪ACE开发人员的主要精力都放在那些方面了？
epoll_data的定义如下：
{
  void *ptr;
  int fd;
  uint32_t u32;
  uint64_t u64;
} epoll_data_t;
如果不用fd，而是用ptr指向对应的event_handler，就可以实现设想的性能改进。不再需要查数据库（repository），wait到event后直接调用handler就可以了。

modern

wishel 在13楼已经把问题说得很清楚了，今天又读了代码确实受益匪浅，
在NONBLOCK FD采用SPECULATIVE READ/WRITE模式，直到读写出现EWOULDBLOCK，
然后由resume_handler_i把oneshot选项设置上，即可达到类似ET的效率。

另外ACE_DEV_POLL_REACTOR分别在在register_handler_i，
mask_ops_i，resume_handler_i三处设置oneshot选项。

确保每次句柄状态改变的时候设置oneshot选项。

[ 本帖最后由 modern 于 2009-11-11 17:46 编辑 ]

modern

14楼听起来是不错的主意，
不过源代码中类似这种建议性的注释多得是，
也不知道是在问谁的?

wishel

原帖由 modern 于 2009-11-11 17:51 发表
14楼听起来是不错的主意，
不过源代码中类似这种建议性的注释多得是，
也不知道是在问谁的?

应该是类似于 //TODO 这样的性质
不过拖这么久时间还不complete，给人感觉好像ACE开发组比较缺人力。