关于ace_dev_poll_reactor
最近在看ace_dev_poll_reactor的源代码，比较郁闷的是发现现在公司看到的和家里看的竟然有大差异。于是比较了ACE的svn上的和公司使用的版本。发现09年6月之前还是蛮稳定的，
从这个时间点开始ace_dev_poll_reactor的改动还是蛮大的。
最大的莫过于对Epoll的使用时之前是一次性所有活动的多个句柄，目前为一次获取一个活动的句柄。
这与上次在wishel发Epoll Proactor时提到的是一样的。于是比较了svn的修改日志。
下面是changelog里面的说明：
Fri Jun 12 00:45:09 UTC 2009Steve Huston<shuston@riverace.com>
* ace/Dev_Poll_Reactor.{h cpp inl}: Fixed multi-thread behavior of
ACE_Dev_Poll_Reactor to resolve Bugzilla 2740, 3178, 3188, 3279.
Note that fixing 3178 involved adding the manual-resume behavior from
ACE_TP_Reactor which was easy after the other fixes. Essentially
what was done is:
- Change epoll_wait() from returning all ready events to just one.
- Registered events now include the EPOLLONESHOT flag, so once
an event is delivered for a handle, no more will be until
epoll_ctl() is called again to reset the events.
This has the effect of suspending handlers around I/O upcalls and
preventing registration changes from happening while another thread
is waiting for events.
* tests/Reactor_Dispatch_Order_Test.cpp:
* tests/Reactor_Dispatch_Order_Test_Dev_Poll.cpp:
* tests/Refcounted_Event_Handler_Test_DevPoll.cpp:
When registering the test handle for events, register for read and
write, not everything. Registering for everything leaves 'connect'
set when 'write' is removed, but they both map to the same event
on non-Windows reactors.
For the _Dev_Poll test, remove the BSD, VxWorks, Lynx-only case for
removing write-mask - this should always be done.
* tests/MT_Reactor_Upcall_Test.cpp: When setting up the
ACE_Dev_Poll_Reactor, set the restart flag.
* tests/Bug_2740_Regression_Test.cpp: Tweaks for more informative
logging and remove false-fails on peer socket closes.
* tests/run_test.lst: Removed !FIXED_BUGS_ONLY from
Bug_2740_Regression_Test.
另外，解决了一个问题之后，貌似又引入了不少新的问题，
看样子ace_dev_poll_reactor的版本一直也没有稳定下来。
因此决定暂时还是不准备在项目中引入ace_dev_poll_reactor勒。 我最近也在研究Dev_Poll_Reactor的机制，但是没有看他的源码，只是在做一个基础测试。
我去年写了一个基于Dev_Poll_Reactor的服务器，同时在线2000人左右问题不大，我用的版本是5.5.6。后来升级了最新的5.7.*程序不如以前稳定（后来又换了回去），确实如楼主所言，感觉Dev_Poll_Reactor越改越不稳定了，或许ACE的开发者们正在尝试新的一些想法，这段时间的成本付出是必须的。
支持楼主一下。 我也想用多线程Dev_Poll_Reactor,折腾了2天,问题多多啊.
1, 首先, 我用的是5.7版本在fc12下.一用多线程(10个)的epoll, CPU消耗100%.gdb进去发现是在锁的消耗上,后来看了别人也有这种现象,是5.7修改后出现的.但开发组说要5.7.7才解决.google 这个(Resolving the CPU-bound ACE_Dev_Poll_Reactor Problem, and more, 用网页快照)
2, 又试了下5.6,但问题更多,而且在fc12下都没编译通过???崩溃ing
3, 后来在fc5上总算编译通过, 用多线程跑了下,出现段错误,是一个包触发了几次读事件,分配几个线程读....
还得继续折腾,现在服务器登录处理时效率实在不够. freeeyes 你写的基于Dev_Poll_Reactor的服务器是多线程的吗?能不能帮忙发给我借鉴下,我看看我写的对不对.
邮箱: zhouwuwang8@126.com 汗。。这个帖子居然才看到。都是给发广告的害的，小小论坛每天都有这么多人发广告。
大家有兴趣的话多试用下我的epoll proactor啊，支持多线程，方便移植到windows，性能也好（理论上，目前我还没做性能测试）。
有问题反馈我马上改。 等我搞定Dev_Poll_Reactor,我就来尝试你的epoll proactor.
计划还要试试半同步半异步的那种模式.
初学者,只能多尝试,现在写的服务器仍然是基于TP_(Select)_Reactor的L\F模式 epoll比poll性能要高很多吧？ 此贴需要关注，大家现在测试情况如何啊？ 回复 2# freeeyes
有没有具体例子看下 回复 2# freeeyes
你好！ 我最近才开始看ace_dev_poll_reactor，想用它支持大量客户tcp连接，但经过测试发现，当连接数达到2000多时，tcp连接会进行的非常慢，这跟服务器的硬件配置有关系吗？多线程下的ace_dev_poll_reactor线程管理怎么办？请大哥多指点。
页:
[1]