水军很多啊
2013-06-18
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的支持,比如对内存的使用等等等等。都要一一吐过也不是不可以,不过就
要耐下性子来慢慢写就是。