打造Epoll Proactor

wishel

最新进度：
实现了schedule timer event，使用的是notification pipe机制。
另外上面所设想的reactor + proactor已经验证，单线程支持select reactor，多线程支持tp和dev_poll reactor，测试案例参考了examples/Reactor/Proactor/test_multiple_loops.cpp。多线程reactor + proactor与多线程纯proactor相比性能差距明显，原因应该是leder/follower的锁粒度太大，只有complete callback才是并发的。而epoll proactro基本上是完全并发。

到此基本上暂告一阶段了，休息，休息一下:lol

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

wishel

注：现在没有大的更新计划，小的features和patch我就不实时在帖子里更新代码了，如果有朋友需要最新版本，请跟帖说下我把最新进度打包发给你。

aidk

好东西！学习一下!!楼主很厉害啊

modern

原帖由 wishel 于 2009-11-28 15:15 发表
最新进度：
实现了schedule timer event，使用的是notification pipe机制。
另外上面所设想的reactor + proactor已经验证，单线程支持select reactor，多线程支持tp和dev_poll reactor，测试案例参考了examples/Reactor/Proact ...

这个项目还有更新么？
想问一下，对于几千连接的情况下有做过测试么？

我最近看了后来更新的支持线程池的代码，
我理解是否理论上，对于大网络连接并发量下，
可以通过适配运行Epoll Proactor的线程池的大小即可。
无须考虑像windows Proactor那样获得异步消息之后，
使用半同步半异步模型进行做消息队列缓冲，
而带来的线程上下文切换的代价。

wishel

最近工作非常忙，暂时停做了。也没做过大的压力测试。
最新的代码改了几个bug，架构上没有什么大的改动。

理论上如果线程没有需要阻塞的地方，线程数设为cpu核数就可以了。否则 cpu * 2，跟网络连接并发量无关。
我使用windows proactor的时候没有用半同步半异步模型，就是没有主动获取异步消息，而是由handle_read_stream（）等中被动处理的。

所以这样可以把线程切换减到最少，理想情况下（处理线程无阻塞）没有切换。

wishel

最新的代码。

modern

表述的有歧义，先删掉。

[ 本帖最后由 modern 于 2010-2-8 09:00 编辑 ]

wishel

proactor 是单线程处理并发连接的逻辑啊。就是说类似select，无论多少连接都是一个线程处理。
但它是并发语义。
引入多线程是为了利用多cpu的能力，而不是用线程并发模型。

所以同一时刻（不是秒不是微秒也不是纳秒），最大能处理 cpu 个事件
而一秒内，能处理的并发连接数与cpu能力有关。

cpu *2只是粗略的算法，理想情况是每一个线程占一个cpu，每个线程顺序处理 网络连接上的io，没有任何线程切换。
在没阻塞的情况下就是cpu，阻塞严重的情况下是cpu*n，一般情况为简化处理，就当做cpu*2

sugar

支持wishel. 因为最近自己变动比较大. 并且正在学习一些东西,所以太忙了. 等闲暇一点. 我会帮你测试的.

[ 本帖最后由 sugar 于 2010-5-18 13:32 编辑 ]

wishel

使用linux的aio库，早些版本（比如Ubuntu 8.10）的AIO库实现有很多问题，现在的10.04已经很好了。
aio完成通知用的是callback routine（ACE用的是复杂的signal），把完成事件注册到notification pipe，可以被epoll wait。数据量小于PIPE_BUF的情况下，pipe的io是原子的，免去了考虑多线程同步的麻烦。

本来说上周完成的，不幸发生惨剧，磁盘分区丢失，所有数据都找不回了。耽误了很多天也没修复好。。
现在只剩ACE_Asynch_Read_Dgram，ACE_Asynch_Write_Dgram，ACE_Asynch_Connect了，预计本周可以完成。
希望大家批评指正，多提宝贵意见，谢谢！！