关于ACE的几个疑惑
学习和使用ACE有些日子了，但发现几个问题比较疑惑，希望大家遇到过的给与解答1、ACE库里面大量的函数的操作错误 比如注册handler失败，就直接返回了-1，至于为什么错误，是哪里错误。库里面没有提供任何日志输出。这样在运行过程中出现的问题，如何追查？难道要自己添加日志么？那么一旦ACE库升级之后，不又要自行添加日志？
2、在posix的proactor模式中 有一个函数find_completed_aio 每次分离出一个completed事件 该函数都要遍历一次数组，从0开始，逐一判断。这玩意不严重影响性能？大家有没有使用的经验，没有经过压力测试，我不敢用这个模式了。
3、FD_SETSIZE的问题。在linux环境下面，使用动态库，通过修改系统的FDSIZE的大小，来解决默认只有1024的问题。但编译静态库结果发现即使改了系统的FDSIZE的大小，也无效。原因不明 1、先搞懂ACE框架运行原理，看一下ACE的例子。不然程序出错，你不知道原因如何调试？
2、posix本来就不适合用proactor，要用reactor的epoll实现。
3、你肯定没改对。不过这个没多少意义，用epoll。 本帖最后由 georgeji 于 2013-5-16 11:27 编辑
使用epoll可以规避fdsize的问题，之前之所以选择select的reactor模式，是因为早先学习了live555代码的影响，live555里面就实现了一个采用select函数分离的reactor模式。在此基础上 对select模式分析的比较清楚。况且在学习C+NP2 ，里面也没有对EPOLL的reactor进行过多的介绍，因此就用select reactor的实现了。
关于库里面log的问题，是因为确实库里面对于返回-1的处理，没有给出打印日志。导致对于发布给客户的程序出现一些问题，而一些问题在实验室里面无法或者很难将问题重现。比如ACE_Select_Reactor_Handler_Repository::bind函数里面 有好几处出现return -1的情况。若是输出一些错误的log或者return 不同的负值也行。这对于开发者排错是很大的帮助。类似的大量的返回return －1的情况很多，都很少有日志输出的。 3. You need to edit a couple system include files to increase the FD_SETSIZE. Since we don't want this change to apply to everything we compile, make backup copies of the files before modifying them.
# cp /usr/include/bits/typesizes.h /usr/include/bits/types.h-bak
# cp /usr/include/linux/posix_types.h /usr/include/linux/posix_types.h-bak
4. Edit those two files and change the "#define __FD_SETSIZE" lines:
#define __FD_SETSIZE 1024 # <- change this
#define __FD_SETSIZE 16384 # <- to this
这是一段时间之前的事情了。编译6.1.4版本的动态库 在上层调试发现fdsize是如期的值，但若采用静态库则依旧是1024。
关于posix 的proactor模式，有些搞不懂了，既然该模式在posix下面存在问题，作者为啥要弄在posix下面的proactor。这个模式有大量的类，我分析了一个周末，做了大量的笔记，画了一些uml图，才有点大功告成的味道，最后分析到find_completed_aio 发现有些不对了。每个读写完成事件 都要进行遍历搜索，这与提高程序性能是背道而驰的。难道作者仅仅是为了可移植性或者是学术方面弄出这么一个东西来？不晓得boost的asio是如何实现的，我在boost的asio里面没有搜索对函数aio_suspend的调用，应该是用了其他办法来处理的。试图学习下。 FD_SETSIZE的问题，我记得很久之前贴过帖子，你检索一下看看？
Proactor在linux下，不是说完全不能用，否则也就丧失了开发的意义了。主要是对于异步操作，unix平台有很多设计、实现上的问题。有的平台，异步操作甚至是用线程模拟的，可想而知，大规模操作情况下性能会有多糟糕。ACE的Proactor在linux下有其它公司改写，但还是推荐使用epoll实现的reactor框架，因为性能已经比较理想，完全不必关心posix平台的问题了。
页:
[1]