9.1分，尼玛，坑谁呢。。。。。
看这里，比较客观
http://ar.newsmth.net/thread-c64b61785ba061.html
muduo适用于什么环境？
muduo的官方一句话自我介绍是：A C++ non-blocking multi-threaded network
library for Linux。
在其readme和wiki中均未提及此lib是否适用于实际场景，于是我花了些时间翻看了一
下，得出的结论是此lib仅限于展示epoll/poll的基本用法，对网络编程初学者是否有参考
价值还有待进一步考察。
任何一个网络产品除了要支持网络event之外，还必须处理另外两种事件：signal和
timer。
muduo也毫无例外。但近看一下就发现muduo对single和timer的支持很有喜感。
除了SIGPIPE被mask之外，muduo没有接管signal。当然muduo这么做是有借口的，反
正有signalfd嘛。在此我想问问各位做网络应用的同学，在你的实际项目中，不用POSIX
的signal接口而用signalfd的，有几个？而如果是从编程初学者教育的角度来看，是介绍
POSIX重要，还是介绍2.6.22引入的一个new feature重要？
而抛弃signal的处理之后，muduo自然轻松了许多，还顺带可以说一句：muduo支持高
级特性signalfd。--嗯，听起来很高级，不过signalfd不是muduo支持的，而是kernel支
持的。
一个网络编程库，timer是重中之重，比到底是用epoll还是select都重要。当然，话说回
来，再吊的库无非也就是个heap为本的数据结构在支持，无非是有些库喜欢说自己的
heap实现比别人都高效，比如haproxy。
但muduo却独辟蹊径，用timerfd，泥玛又是一个高级特性啊，很唬人的。由kernel帮你
管理timer，是不是很吊。
不仅采用了timerfd，muduo还采用了set来保存event，每个big loop里要查超时的时
候，再iterate一遍这个set。
再然后，每次加一个timer，就要冒着一次settime的syscall的风险--这还不够，还得要一
次gettimeofday。别不把syscall当不要钱的可以吗？
你也许可以跑10万个连接，但你敢加上超时的特性吗？muduo如果有做过细致的
benchmark就会知道，一个loop里最花时间的就是timer的处理。
关于muduo的timer处理，槽点太多，我就不一一细述了。回头看看timer，很显然不适
合工业应用，而给初学者做参考。。。嗯，负面参考价值很大。
嗯，今天先说这么多吧。吐槽点还很多，比如那个全功能的http范例，比如对
pthread/fork的支持，比如对内存的使用等等等等。都要一一吐过也不是不可以，不过就
要耐下性子来慢慢写就是。
lz的这种喷法我不同意。我有项目在用，起码现在看来，muduo在它说的特定应用场景中，性能并不是问题。而且在我看来，作者的代码问题不是很大。虽然作者代码中有很多unsafe的FIXME，但是并不能掩盖它的优点。
作者也说过适用场景，并且作者的出发点也是一个特定平台的好用，易用的网络库。而且作者之前在摩根斯坦利公司上班，现在在谷歌上班，你觉得这样背景的人会不懂你说的那些问题？
http://www.parallell
我现在正在看这本书，还没看完，但据目前是看的觉得这本书还是不错的，主要作者的经验之谈，很有参考价值。而这个库其实应该只是教学研究用，介绍一些原理性的东西。总之这本书还不错，值得去读。
这个评述者倒是有点傻逼。。。
看似写得很犀利，楼主还是给个profile来说明吧。 自己实现一个，或者用开源库对比一下。talk is cheap, show me the code！
要想学会高并发网络编程，kernel的system call是必须要会的；这之后其实用c可以很简单高效的实现高并发，nginx就是这么做的。
而muduo采用的c++，隐藏了kernel的system call，还引入了c++自身的复杂性，让人很难去捕捉到真正的实质。
本书作为c++学习教程其实是更合适的...
这都是这些什么理由啊，要黑一样东西也请黑得有点水平好吧。
1. timefd和signalfd。
linux提供新的timefd和signalfd的初衷，就是想通过select/poll/epoll来统一事件处理方式。既然有降低开发难度的API，为什么还要绕道去使用不好用的？像POSIX signal API这种，在多线程环境下会极大增加开发难度的东西，为什么不能用一个signalfd一笔带过？
至于说“在此我想问问各位做网络应用的同学，在你的实际项目中，不用POSIX的signal接口而用signalfd的，有几个？”这个，我只想说，去看看BSD的kqueue好吧。
如果看过boost.asio的源码的话，会发现ASIO虽然没有用signalfd，但timer的实现却是用了timerfd。当然，楼主也可以说ASIO也很渣，这我无话可说。
2. 用std::set保存timer queue。
"muduo还采用了set来保存event，每个big loop里要查超时的时候，再iterate一遍这个set。" 这个说明了楼主根本就没看懂timer queue的实现。timer queue是一个按timer先后顺序排序的一个集合，设置timerfd时，只需要设置queue的第一个事件，触发timer事件时也只需要取出queue里第一个operation来执行，根本不需要iterate整个set。只是插入时会慢一点，但通常timer queue的实现都会用二叉排序树来管理timer queue，所以插入时也不会有太大的影响。
而且这种方式已经是业界标准做法了好吧，libuv实现且使用了RB_XXX宏，ASIO在timer_queue.hpp中自己用双向链表和std::vector实现了二叉排序树，而muduo使用std::set却恰恰是最易理解且不损失效率的方式，因为std::set文档很清楚地说了，“Sets are usually implemented as red-black trees."
至于说用muduo跑带超时的10万个连接，我没用过muduo，不能臆测。但我能肯定的是，即使是muduo不能，也绝对不会是楼主所描述的理由。
另外像楼上那位fffvvvzz，水平渣得不一般，居然妄图用volatile管理多线程里的共享变量，已经被批成渣的东西了好吧，就这水平也好意思说作者对多线程不熟悉，你才是真敢写啊。
没看书，随便看了下在googlecode上的源代码，感觉作者属于玩票性质的。
1.的确像楼主说的那样，作者对信号不熟悉，epoll_wait出错后连EINTR都没判断
2.作者对多线程也不熟悉，线程的quit_变量，连volatile修饰也没有
只能说程序正好能运行起来，但是达不到可靠，更不用说是库级别的了
结论：1.作者真敢写 2.豆瓣水军多或读者层次低