疑问：proactor的aio为什么不增加基于epoll实现

wesom

boost.asio在linux下据说是用epoll实现，我没看源码，proactor中却无epoll，ace的大佬们把epoll放入ACE_Dev_Poll_Reactor中实现，不知是什么原因？epoll难道不是标准Posix aio语意？
那boost.asio的epoll是如何模拟aio的？

freeeyes

epoll本身并非异步模式，它属于Reactor模型。

wesom

epoll非Posix aio语义，它和select都有多路复用的意思，那boost.asio是如何通过epoll实现异步模式？
如果boost实现了的话，proactor按道理应该也可以。貌似wishel已经在做这个工作了，http://www.acejoy.com/bbs/viewth ... ;highlight=Proactor
to freeeyes，看看这2个结论是否有错误：
1、epoll原意是多路复用，但大部分linux下的异步模式还是可以通过epoll模拟实现的。
2、ace自带没有通过epoll实现的proactor，boost.asio通过epoll实现了aio。

freeeyes

epoll和AIO是不一样的东西。
是可以用epoll的基础模拟一个AIO的标准，但是本质还是reactor，你只能在上层做线程队列。其实内核不支持，AIO的效能提升是有限的。ACE把epoll列为reactor并非有什么问题。除非linux内核支持异步模式。
另外Boost的ASIO我没有看过，不知道内部实现。不过我觉得epoll足够了。

modern

楼主有几个概念没弄清楚：
select、poll、epoll系统API同属于IO复用模型（但是对于IO这个动作，属于同步IO）
而IOCP、linux AIO均属于异步IO（AIO）
异步IO与同步IO最大的区别在于，IO这个读写动作是由谁来完成的。
由用户完成的可认为是同步IO，由系统或者库完成的可近似认为是异步IO。

boost实现的ASIO库的epoll实现的原理与wishel实现的epoll Proactor版本原理上差不多，
都是都是库一级别处理的epoll_wait得到的读、写或异常事件通知，
由库内部线程完成读写，然后这个读写完成的事件可以被用户查询出来并处理。
到这里我们可以近似的认为库已经提供了异步IO的能力。

我们熟悉IOCP即是由微软的操作系统直接提供的API原语，
说白也是微软内存搞了一个线程池做了相同的事情，
然后提供了一个获取完成端口队列消息（GetCompeletePortQueues）的API函数使用户可以 将完成信息查询出来。

但是库的好处是又进一步帮你做了很多事情，
比如提供用户对该handle注册的回调函数的能力（比如读，写，timer，信号等等），
在内部线程完成某类事件之后，直接通过对应的事件回调函数通知用户，
显然这就是源于ACE的proactor模型啦。

modern

ACE_Dev_Poll_Reactor使用leader/follower线程池模型与epoll的lt模型。
由于可以没有内部线程切换的代价，因此理论上处理大规模网络连接且一定时间内平稳并发的情况，
会有不错的性能。如果考虑伸缩能力亦可以扔到ACE_Task的message_queue中统一处理。

不过记得从ACE5.6.9开始好像这个dev_poll一直改来改去，
纠结于epol_wait是一个返回一个事件，还是一次返回多个事件。
最近这几个版本就没有再关注了。

对于dev_poll，一些用过的人反映不是很好，不过缺少实际性能测试的数据，不给力呀！

freeeyes

dev_poll我用过，linux下提供一个服务，还可以吧，没有出过什么错。当然，压力不大，一天也就5000-6000次请求。

wesom

谢谢modern和freeeyes详细清晰的解说。。。

wesom

ACE_Dev_Poll_Reactor使用leader/follower-->这个也是？印象中只有ACE_TP_Reactor吧，按wishel所描述，每次只wait 1个fd，多线程调epoll_wait只有一个线程返回,不能算L/F，There is no need to set the owner of the event loop for the ACE_Dev_Poll_Reactor.  Multiple threads may invoke the
event loop simulataneously.

wesom

可能是ace版本不同，实现不同吧。。。