整体感觉：ACE太庞大，asio 太赶时髦。

ACE太过庞大，使得你即便是只使用它的一小部分，也不得不引用它的全部。而且框架一大堆，模式一个加一个，很多编程习惯也要改变。学习曲线太陡，也难以将它作为一个模块集成自己的应用。

asio呢，有个牛大大说它是现时代的ACE，我觉得比较中肯。用bind做回调也并不比虚函数好，看上去灵活了，代价却更高了。我说的不光是运行时的内存和时间代价，更重要的编译时间难以忍受。

apr大约只是一个平台无关的api封装，相对来说比较轻量级。

libevent就更轻量级了，轻量级到无法把它当成一个平台无关的socket，还要写很多平台相关的代码。

相比而下，我觉得apr还好点，其实我需要的只是一个机制，而不是一个完整的策略，这是unix的哲学。如果仅就异步通讯来说，我觉得linux.epoll是最好的，简单、直接、有效，如果在每个平台上都有epoll可用，所有其它封装在我看来都是多余的了。

proactor真的就比reactor高效吗？它更多的是一种策略，据说Windows的操作系统级IOCP是用线程池实现的，它能高效到哪里去？

变量的命名规则，一般有这么几种：

1. 骆驼规则，如 Windows Api 的命名规则（CreateFile/GetDiskFreeSpaceEx），Java 类名的规则 

2. 首单词小写，如Java方法名（readByte）

3. 下划线分隔单词，如C++标准库（lower_bound/equal_range）

4. 全部小写，无分隔，如unix(posix)的很多函数名（getpagesize），但这类大部分使用所写（mmap/sysconf）

5. 骆驼规则再加下划线，ACE使用这种规则（ACE_Event_Handler ）

6. C 宏名命名规则，一般是全部大写，再加下划线（BOOST_CURRENT_FUNCTION/BOOST_STATIC_CONSTANT）

7. Windows 中使用一个变种，全部大写，类别前缀加下划线，再加单词连写（WM_ACTIVATETOPLEVEL）

8. 全部大写，无分隔，如Windows中的结构名

这几种规则，我个人认为最坏的是【8】，然后是【7】，全部大写不加单词分隔很难辨别（单词界线）。【3】在名称比较短时还行，这类名称一般也的确比较短。

这几种命名规则，我个人觉得都不太好，主要是在视觉是感觉不好，以下就举一些反例（最被大家看好的）：

【1】. GlobalAlloc，ReadFile，单词的分界在视觉上感觉不舒服，主要是以f/l/d/作为分界时，和下一个单词的首字母大写有些混淆，【2】的缺点跟【1】一样。

【3】. 下划线分隔，有时略显啰嗦，如getpage，就比get_page，来得简明舒服一些

目前该框架（DataIO）仅支持二进制。想起序列化支持只需要两个宏 DATA_IO_LOAD_SAVE / DATA_IO_LOAD_SAVE_V，对象成员基本上用“&”连接起来，这样，可以写一个简单的语法分析器，在序列化宏中将成员序列化表达转化成字符串， 继续阅读 →

 这段时间一直想用Coroutine来实现我的rpc中异步调用的分派。看了很多Coroutine的资料，感觉它比起线程切换，就是少了个内核调用，少了自动激活，以及一些内和支持的线程状态（errno,tls等）。在处理器状态的存储/恢复，堆栈的切换等方面的开销都是一样的。在x86这样的体系结构下，处理器的状态（寄存器状态）很少，就那么几个寄存器，存储/恢复起来很快。但是，象MIPS，甚至Itanium这样的体系结构，他们的寄存器很多，Itanium甚至有128个64位的寄存器，这样，光寄存器状态就要1024byte！存储/恢复的开销很大。

有时也想，在没有Coroutine的普通函数调用中（不需要切换堆栈），编译器可以使用一些寄存器分配算法，来有效利用寄存器。如果在语言支持的Coroutine中，是否可以通过类似的方式减轻Coroutine切换开销？

严格讲，是不需要专用的 IDL 语言，传统 RPC 的 IDL 语言 相应的部分 在这里全部是 C++ 语言本身，也可以把它称作 IDL，是由几个宏实现的： 继续阅读 →