2012年6月30日下午將在深圳做《Muduo 網絡庫：現代非阻塞C++網絡編程》演講，
這是PPT：
http://www.slideshare.net/chenshuo/muduo-network-library
演講視頻：
http://v.youku.com/v_show/id_XNDIyNDc5MDMy.html
http://youtu.be/YDnCAs894Bg
活動介紹：
http://ouropensource.51qiangzuo.com/
posted on 2012-07-01 23:55 陳碩 閱讀(5491) 評論(29) 編輯 收藏 引用 所屬分類: muduo
看過這個代碼，對其中一些設計很不感冒例如 channel明明可以設計成虛函數接口，結果卻硬是用std::function去擼陳碩估計老是想著用function了。卻忘記了虛函數的使用。例如用boost::bind取代虛函數這篇文章。一個對象級別的函數指針當然可以取代類級別的虛函數，問題是我需要用大炮打蚊子嗎？類帶一個函數指針與每個對象都帶一個函數指針，拋開別的不說，就內存都要節省一些。而且用了boost::function調試起來看到一塊塊模板棧是不是有想死的感覺?這也算是學會用std::function std::bind的一些人的通病了，啥地方都去用std::function。有玩弄技巧之嫌。說個搞笑的事情，我們原來的頭自從學會用bind這個東西后，沒有bind就寫不出代碼了…… 回復 更多評論
@唐詩如果把Channel class設計成虛函數接口，那么在下面這五處用到Channel事件回調的地方，要么各自派生一個 inner DerivedChannel class，要么他們都直接繼承Channel，兩種做法問題都更大。Acceptor::acceptChannel_Connector::channel_EventLoop::wakeupChannel_TcpConnection::channel_TimerQueue::timerfdChannel_另見：muduo.chenshuo.com/2012/07/modern-c-api-in-muduo-part-1.html 回復 更多評論
總是沒有c來的簡潔 回復 更多評論
void EventLoop::runInLoop(const Functor& cb)函數中,wakeup可能會被調用2次第一次 在queueInLoop中第二次 自己調用 回復 更多評論
@楊軍謝謝，會在下一版修正。 回復 更多評論
@陳碩Channel class設計成虛函數，直接繼承Channel有啥問題？ 回復 更多評論
@唐詩你的意思是說：Acceptor is-a ChannelConnector is-a ChannelEventLoop is-a ChannelTcpConnection is-a ChannelTimerQueue is-a Channel像這樣建模？OO 中毒太深了吧？ 回復 更多評論
@陳碩為什么不可以？理由？ 回復 更多評論
@唐詩除了我前面給的鏈接里那篇文章里給的原因，更重要的理由就是：我認為這么建模是錯的。Acceptor is-not-a Channel, Acceptor uses a Channel to get readable event notification.Connector is-not-a Channel, Connector uses a Channel to get writable event notification.如此等等。在muduo里，EPollPoller is-a Poller,PollPoller is-a Poller.因此這里用了虛函數。其他地方 is-a 關系不成立。繼承不是為了復用，而是為了被復用。 回復 更多評論
@陳碩更重要的理由就是：我認為這么建模是錯的。Acceptor is-not-a Channel, Acceptor uses a Channel to get readable event notification.Connector is-not-a Channel, Connector uses a Channel to get writable event notification.這只是文字上的理解的區別，既然可以用虛函數，那必然可以換個理解,例如：我們可以這么理解, 把Channel改個名字EventHandlerAcceptor is a EventHandlerConnector is a EventHandler 回復 更多評論
@唐詩改成 EventHandler 一樣是錯的，is-a 關系必須滿足 Liskov 替換原則：凡是程序里需要用到 EventHandler 的地方，換成它的任何一個派生類都是可行的。但是顯然 Acceptor、Connector 等等不具備這種可替換性。 回復 更多評論
TimerQueue::getExpired函數中assert(end == timers_.end() || now < end->first);應該改為now<=end->first吧或者用upper_bound代替lower_bound 回復 更多評論
@楊軍不改。你寫個程序測一測吧。 回復 更多評論
@陳碩Liskov 替換原則是個過于理想化的原則，實際使用中需要權衡 回復 更多評論
iterator lower_bound ( const key_type& x ) const;返回一個指向大于或者等X值的第一個元素的迭代器。 返回一個指向容器中第一個大于或等于x值的元素的迭代器參數x要比較的值返回值返回一個指向容器中第一個大于或等于x值的元素的迭代器#include <iostream>#include <set>using namespace std;int main (){ set<int> myset; set<int>::iterator it,itlow,itup; for (int i=1; i<10; i++) myset.insert(i*10); // 10 20 30 40 50 60 70 80 90 itlow=myset.lower_bound (30); // ^ itup=myset.upper_bound (60); // ^ myset.erase(itlow,itup); // 10 20 70 80 90 cout << "myset contains:"; for (it=myset.begin(); it!=myset.end(); it++) cout << " " << *it; cout << endl; return 0;} 回復 更多評論
@楊軍你認為 muduo 代碼中的 UINTPTR_MAX 的作用是什么？https://gist.github.com/3059083 回復 更多評論
喔,受教了,麻煩了啊 回復 更多評論
size_t n = connections_.erase(conn->name()); (void)n;經常看你在返回值前面加一個void,這是為什么啊 回復 更多評論
@楊軍你試試去掉它，然后用 BUILD_TYPE=release ./build.sh編譯。 回復 更多評論
@陳碩了解，不過(void)n;這種類似的語句也會帶來額外的代碼在C#里面，經常用2套代碼#DEBUG#END#RELEASE#END來解決，不過太繁瑣了，不知道有沒有更優雅的解決辦法 回復 更多評論
@楊軍> 不過(void)n;這種類似的語句也會帶來額外的代碼Are you sure? 回復 更多評論
一定要糾結學術上的Liskov 替換原則可以設計兩個一模一樣的接口,ConnectionEventHandler和DataEventHandler,兩者成員函數完全一樣，Acceptor、Connector 分別繼承這兩個類，這樣也比到處是boost::bind要好，core掉的時候就不用看著到處的模板目瞪口呆了不過，既然是一模一樣，順其自然到不如就共用一個接口類了 回復 更多評論
@唐詩ConnectionEventHandler 和 DataEventHandler 二者的成員函數當然不一樣，Connector 關心的是 writable event，Acceptor 關心的是 readable event。說到底你說因為debug的原因而影響設計，但是 boost::bind 真的有那么難調試嗎？我故意制造一個core dump，調用棧一樣容易看嘛。一眼看出 muduo::net::Channel::handleEventWithGuard 調用了 cdns::Resolver::onRead，有困難嗎？(gdb) bt#0 cdns::Resolver::onRead (this=0x7ffff7c7ee90, sockfd=6, t=...) at /home/schen/muduo/examples/cdns/Resolver.cc:102#1 0x000000000041011a in boost::function1<void, muduo::Timestamp>::operator() (this=0xc32ae0, receiveTime=<value optimized out>) at /usr/include/boost/function/function_template.hpp:1013#2 muduo::net::Channel::handleEventWithGuard (this=0xc32ae0, receiveTime=<value optimized out>) at /home/schen/muduo/muduo/net/Channel.cc:90#3 0x00000000004102fb in muduo::net::Channel::handleEvent (this=0xc32ae0, receiveTime=<value optimized out>) at /home/schen/muduo/muduo/net/Channel.cc:65#4 0x00000000004131b5 in muduo::net::EventLoop::loop (this=0x7ffff7c7ede0) at /home/schen/muduo/muduo/net/EventLoop.cc:122#5 0x000000000040d5c2 in main (argc=<value optimized out>, argv=0x7ffff7c7f0a8) at /home/schen/muduo/examples/cdns/dns.cc:51 回復 更多評論
server_threaded_efficient和server_threaded_highperformance算法太精妙了，看了回味無窮啊，太牛逼了 回復 更多評論
你好，我最近想搞個網絡服務器，參考了你的muduo代碼，在閱讀過程中，有些地方有點疑問，希望解答，謝謝。 1、epoll_wait檢查到有準備好io的描述符后，在獲取描述符的時候執行了： 96 channel->set_revents(events_[i].events); 修改了chanel里關注的event為epoll_wait當前檢查到的event，并在后面的： void Channel::handleEventWithGuard(Timestamp receiveTime) 直接取 revents_ 與EPOLLIN等進行比較，有個問題，如果原來某個描述同時關注In和out事件，這時客戶端消息來了，可讀，則因為 set_revents（）的調用，以后就不會再關注out事件了，這樣會導致有些數據不會寫入socket？ 2、 72 void TcpConnection::send(const void* data, size_t len)中： 82 string message(static_cast<const char*>(data), len); ===直接用string，如果data中含有二進制數據，如0，不是會丟失嗎，而且如果這個段data很長，會發生一次數據拷貝吧？ 關于send的問題，我現在希望從業務邏輯線程往某個socket寫數據，我想可以直接先試著寫入socket的buff，然后失敗才寫到connection的緩沖區中，并吧socket的epoll狀態modify為也關注out，這樣是否有問題呢？ 回復 更多評論
@xxf 第一個問題應該是我錯了，此處只是修改了應用程序中的event，而epoll中還是繼續關注原先的事件。 第二個關于緩沖區的問題，如果其他某個線程x要發送數據到某個socket，應該是遞交一個請求給io線程y，而不應該直接在x線程中直接send，也就是吧io操作都集中到x線程中，直覺應該是這樣，否則x線程就可能因為send失敗而進行其他的或者反復的io，是否還有其他理由呢？ 在此類操作非常熱門頻繁的情況下，比如某個線程從另一個進程接受數據，然后要用io線程中的某個socket給客戶端轉發這個消息，如果用muduo中的send(void*, size_t len)方式，會發生大量的內存new、delete操作，是否可以考慮直接遞送給connection的send_buf? 回復 更多評論
@xxf2. 直接用string，如果data中含有二進制數據，如0，不是會丟失嗎，而且如果這個段data很長，會發生一次數據拷貝吧？有'\0'也不會丟失，你試試就知道。如果跨線程發送消息，是會有一次拷貝，在C++11里可以用 move semantic 解決。 回復 更多評論
@陳碩非常支持博主的分享精神；我重點關注了博主對tcp發送數據的處理；確實wakeup會調用多次；另外eventfd的一對read/write操作，接近300W次/s(至強E5-2650)感覺還是有點耗；不知是否能從程序角度盡量減少這種為發數據所做的喚醒。該問題我考慮了幾天，但結論僅僅是在tcpsocket注冊了EPOLLOUT時不需要喚醒，一旦數據發送完全，移除EPOLLOUT事件，每次發數據還是需要喚醒的 回復 更多評論
@bertyoung真要在乎這個，就不要跨線程發送數據。當前IO線程發送數據是不會wakeup的。 回復 更多評論
Powered by: C++博客 Copyright © 陳碩