摘要： 整体感觉：ACE太庞大，asio 太赶时髦。ACE太过庞大，使得你即便是只使用它的一小部分，也不得不引用它的全部。而且框架一大堆，模式一个加一个，很多编程习惯也要改变。学习曲线太陡，也难以将它作为一个模块集成自己的应用。asio呢，有个牛大大说它是现时代的ACE，我觉得比较中肯。用bind做回调也并不比虚函数好，看上去灵活了，代价却更高了。我说的不光是运行时的内存和时间代价，更重要的编译时间难以忍受。apr大约只是一个平台无关的api封装，相对来说比较轻量级。libevent就更轻量级了，轻量级到无法把它当成一个平台无关的socket，还要写很多平台相关的代码。相比而下，我觉得apr还好点，其 阅读全文

摘要： 变量的命名规则，一般有这么几种：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_CUR 阅读全文

摘要： 项目地址：http://code.google.com/p/febird目前该框架（DataIO）仅支持二进制。想起序列化支持只需要一个宏DATA_IO_LOAD_SAVE/DATA_IO_LOAD_SAVE_V，对象成员基本上用“&”连接起来，这样，可以写一个简单的语法分析器，将成员序列化表达转化成字符串，然后进行语法分析，这样，就可以在不用改变客户代码的情况下，进行文本方式（如XML）的序列化了，比boost的要简单许多。如，目前的宏这样定义：#defineDATA_IO_LOAD_SAVE(Class,Members)/ templatevoidload(DataIO&d 阅读全文

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

摘要： 项目地址：http://code.google.com/p/febirdIDL的数据定义由几个宏定义实现：RPC_DECLARE_MF(FunName, ArgList)声明函数，ArgList必须带括号BEGIN_RPC_REGISTER_MF_EX(ThisClass,ClassName)BEGIN_RPC_REGISTER_MF(ThisClass)开始注册函数EX后缀可以使用指定的名字作为类名称RPC_REGISTER_MF(FunName)注册一个函数END_RPC_REGISTER_MF()结束注册用起来很类似于微软MFC中的消息映射声明。实现上有过几次改动：初始完成l 每个Cli 阅读全文

摘要： 在现实世界中，基本是是按着这样的顺序演化：process-->thread-->coroutine/fiber其实是一个context切换开销从大到小的演化，process切换开销最大，需要切换地址空间，所有的CPU状态，所有其他资源thread切换只需要切换CPU状态，当然是大部分的CPU状态，而coroutine切换，只需要切换很少的CPU状态，而且全部都在用户地址空间运行，不需要到内核空间。当然，切换coroutine的开销还是比一次函数调用大很多，其实函数调用也是一个cpu状态的切换，不过这个状态要少得多，在x86 windows 上，甚至不必保存所有的寄存器状态（EAX/ 阅读全文

摘要： boost::shared_ptr 对象中，有两个成员一个是对象 ptr，一个是引用计数类的指针，由于某种原因，我希望把 shared_ptr 放入一个指针大小的地方，却无法实现，只能用 intrusive_ptr，但是牵涉到的类又太多，改起来不现实，仔细想一下，其实 shared_ptr 完全可以只有一个指针大小，只要把对象指针放到引用计数类中就可以了，为什么shared_ptr作者不这么干？是他没想到？我觉得不太可能。或者只是为了减少一次内存访问？我觉得也不太可能。这到底有什么更深层次的原因？ 阅读全文

摘要： 前段时间自作聪明的还以为自己发现了一个完美的解决异步IO的方法，还真太把自己当回事了。人家已经早有这个办法了，还有个学名，叫做Coroutine，在异步IO中的应用也已经非常多了，我真是太孤陋寡闻了。 阅读全文

摘要： 刚才看coroutine，在这个页面感觉最有意思的是这一段话：(The header file is MIT-licensed, so you can use it in anything you like without restriction. If you do find something the MIT licence doesn't permit you to do, mail me, and I'll probably give you explicit permission to do it anyway.) 阅读全文

摘要： 在异步通讯中，一般使用一个线程来select/poll/epoll，收到信号后，解码消息头，或者整个消息，然后将相应的fd交给其他线程处理。这看上去的确是个很好的办法，但是，如果使用Tcp，并且遇到一个复杂的派发过程：收到的消息大小未知，而只能使用序列化方法解码消息然后根据其内容进行派发。这种情况的特征是：在大多数情况下，都可以无阻塞地读取并解码整条消息，但也有极小的可能在某条消息上阻塞（消息不完整）。这种情况往往使用线程池，select线程一得到可读信号，就把相应的fd交给线程池处理。这样是解决了问题，但是又有个新问题：线程切换的开销太大。如果在高速局域网内，并且每个请求的实际执行时间非常短 阅读全文