陳碩的Blog

評(píng)論

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-05 19:49 唐詩

看過這個(gè)代碼，對(duì)其中一些設(shè)計(jì)很不感冒
例如 channel明明可以設(shè)計(jì)成虛函數(shù)接口，結(jié)果卻硬是用std::function去擼

陳碩估計(jì)老是想著用function了。卻忘記了虛函數(shù)的使用。
例如用boost::bind取代虛函數(shù)這篇文章。一個(gè)對(duì)象級(jí)別的函數(shù)指針當(dāng)然可以取代
類級(jí)別的虛函數(shù)，問題是我需要用大炮打蚊子嗎？類帶一個(gè)函數(shù)指針
與每個(gè)對(duì)象都帶一個(gè)函數(shù)指針，拋開別的不說，就內(nèi)存都要節(jié)省一些。而且用了boost::function調(diào)試起來看到一塊塊模板棧是不是有想死的感覺?

這也算是學(xué)會(huì)用std::function std::bind的一些人的通病了，啥地方都去用std::function。有玩弄技巧之嫌。

說個(gè)搞笑的事情，我們?cè)瓉淼念^自從學(xué)會(huì)用bind這個(gè)東西后，沒有bind就寫不出代碼了……  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 08:00 陳碩

@唐詩
如果把Channel class設(shè)計(jì)成虛函數(shù)接口，那么在下面這五處用到Channel事件回調(diào)的地方，要么各自派生一個(gè) 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  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 10:19 zjh

總是沒有c來的簡潔  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 11:23 楊軍

void EventLoop::runInLoop(const Functor& cb)
函數(shù)中,wakeup可能會(huì)被調(diào)用2次

第一次 在queueInLoop中
第二次 自己調(diào)用  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 12:09 陳碩

@楊軍
謝謝，會(huì)在下一版修正。  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 13:44 唐詩

@陳碩
Channel class設(shè)計(jì)成虛函數(shù)，直接繼承Channel有啥問題？  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 13:51 陳碩

@唐詩
你的意思是說：
Acceptor is-a Channel
Connector is-a Channel
EventLoop is-a Channel
TcpConnection is-a Channel
TimerQueue is-a Channel
像這樣建模？
OO 中毒太深了吧？  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 15:14 唐詩

@陳碩
為什么不可以？理由？  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 15:31 陳碩

@唐詩
除了我前面給的鏈接里那篇文章里給的原因，
更重要的理由就是：我認(rèn)為這么建模是錯(cuò)的。
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.
因此這里用了虛函數(shù)。其他地方 is-a 關(guān)系不成立。

繼承不是為了復(fù)用，而是為了被復(fù)用。  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 15:56 唐詩

@陳碩
更重要的理由就是：我認(rèn)為這么建模是錯(cuò)的。
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.

這只是文字上的理解的區(qū)別，既然可以用虛函數(shù)，那必然可以換個(gè)理解,例如：

我們可以這么理解, 把Channel改個(gè)名字EventHandler

Acceptor is a EventHandler
Connector is a EventHandler  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 16:14 陳碩

@唐詩
改成 EventHandler 一樣是錯(cuò)的，is-a 關(guān)系必須滿足 Liskov 替換原則：
凡是程序里需要用到 EventHandler 的地方，換成它的任何一個(gè)派生類都是可行的。
但是顯然 Acceptor、Connector 等等不具備這種可替換性。  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 16:23 楊軍

TimerQueue::getExpired函數(shù)中

assert(end == timers_.end() || now < end->first);

應(yīng)該改為now<=end->first吧
或者用upper_bound代替lower_bound  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 17:03 陳碩

@楊軍
不改。你寫個(gè)程序測(cè)一測(cè)吧。  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 17:38 唐詩

@陳碩
Liskov 替換原則是個(gè)過于理想化的原則，實(shí)際使用中需要權(quán)衡  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 18:10 楊軍

iterator lower_bound ( const key_type& x ) const;
返回一個(gè)指向大于或者等X值的第一個(gè)元素的迭代器。

返回一個(gè)指向容器中第一個(gè)大于或等于x值的元素的迭代器

參數(shù)
x
要比較的值

返回值
返回一個(gè)指向容器中第一個(gè)大于或等于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;
}
  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 18:21 陳碩

@楊軍
你認(rèn)為 muduo 代碼中的 UINTPTR_MAX 的作用是什么？
https://gist.github.com/3059083  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-06 18:56 楊軍

喔,受教了,麻煩了啊  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-07 17:50 楊軍

size_t n = connections_.erase(conn->name());
(void)n;

經(jīng)?？茨阍诜祷刂登懊婕右粋€(gè)void,這是為什么啊  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-07 18:05 陳碩

@楊軍
你試試去掉它，然后用
BUILD_TYPE=release ./build.sh
編譯。  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-08 23:11 楊軍

@陳碩
了解，不過(void)n;這種類似的語句也會(huì)帶來額外的代碼
在C#里面，經(jīng)常用2套代碼
#DEBUG
#END

#RELEASE

#END

來解決，不過太繁瑣了，不知道有沒有更優(yōu)雅的解決辦法  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-08 23:54 陳碩

@楊軍
> 不過(void)n;這種類似的語句也會(huì)帶來額外的代碼

Are you sure?  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-10 02:07 唐詩

一定要糾結(jié)學(xué)術(shù)上的Liskov 替換原則可以設(shè)計(jì)兩個(gè)一模一樣的接口,ConnectionEventHandler和DataEventHandler,兩者成員函數(shù)完全一樣，Acceptor、Connector 分別繼承這兩個(gè)類，這樣也比到處是boost::bind要好，core掉的時(shí)候就不用看著到處的模板目瞪口呆了

不過，既然是一模一樣，順其自然到不如就共用一個(gè)接口類了  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-10 08:42 陳碩

@唐詩
ConnectionEventHandler 和 DataEventHandler 二者的成員函數(shù)當(dāng)然不一樣，Connector 關(guān)心的是 writable event，Acceptor 關(guān)心的是 readable event。


說到底你說因?yàn)閐ebug的原因而影響設(shè)計(jì)，但是 boost::bind 真的有那么難調(diào)試嗎？
我故意制造一個(gè)core dump，調(diào)用棧一樣容易看嘛。

一眼看出 muduo::net::Channel::handleEventWithGuard 調(diào)用了 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
  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-22 12:27 楊軍

server_threaded_efficient
和server_threaded_highperformance
算法太精妙了，看了回味無窮啊，太牛逼了  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-24 17:39 xxf

你好，我最近想搞個(gè)網(wǎng)絡(luò)服務(wù)器，參考了你的muduo代碼，在閱讀過程中，有些地方有點(diǎn)疑問，希望解答，謝謝。

1、epoll_wait檢查到有準(zhǔn)備好io的描述符后，在獲取描述符的時(shí)候執(zhí)行了：
96 channel->set_revents(events_[i].events);
修改了chanel里關(guān)注的event為epoll_wait當(dāng)前檢查到的event，并在后面的：
void Channel::handleEventWithGuard(Timestamp receiveTime)
直接取 revents_ 與EPOLLIN等進(jìn)行比較，有個(gè)問題，如果原來某個(gè)描述同時(shí)關(guān)注In和out事件，這時(shí)客戶端消息來了，可讀，則因?yàn)?set_revents（）的調(diào)用，以后就不會(huì)再關(guān)注out事件了，這樣會(huì)導(dǎo)致有些數(shù)據(jù)不會(huì)寫入socket？

2、 72 void TcpConnection::send(const void* data, size_t len)中：
82 string message(static_cast<const char*>(data), len);
===直接用string，如果data中含有二進(jìn)制數(shù)據(jù)，如0，不是會(huì)丟失嗎，而且如果這個(gè)段data很長，會(huì)發(fā)生一次數(shù)據(jù)拷貝吧？
關(guān)于send的問題，我現(xiàn)在希望從業(yè)務(wù)邏輯線程往某個(gè)socket寫數(shù)據(jù)，我想可以直接先試著寫入socket的buff，然后失敗才寫到connection的緩沖區(qū)中，并吧socket的epoll狀態(tài)modify為也關(guān)注out，這樣是否有問題呢？  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-25 14:22 xxf

@xxf
第一個(gè)問題應(yīng)該是我錯(cuò)了，此處只是修改了應(yīng)用程序中的event，而epoll中還是繼續(xù)關(guān)注原先的事件。

第二個(gè)關(guān)于緩沖區(qū)的問題，如果其他某個(gè)線程x要發(fā)送數(shù)據(jù)到某個(gè)socket，應(yīng)該是遞交一個(gè)請(qǐng)求給io線程y，而不應(yīng)該直接在x線程中直接send，也就是吧io操作都集中到x線程中，直覺應(yīng)該是這樣，否則x線程就可能因?yàn)閟end失敗而進(jìn)行其他的或者反復(fù)的io，是否還有其他理由呢？
在此類操作非常熱門頻繁的情況下，比如某個(gè)線程從另一個(gè)進(jìn)程接受數(shù)據(jù)，然后要用io線程中的某個(gè)socket給客戶端轉(zhuǎn)發(fā)這個(gè)消息，如果用muduo中的send(void*, size_t len)方式，會(huì)發(fā)生大量的內(nèi)存new、delete操作，是否可以考慮直接遞送給connection的send_buf?  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-07-26 18:33 陳碩

@xxf
2. 直接用string，如果data中含有二進(jìn)制數(shù)據(jù)，如0，不是會(huì)丟失嗎，而且如果這個(gè)段data很長，會(huì)發(fā)生一次數(shù)據(jù)拷貝吧？

有'\0'也不會(huì)丟失，你試試就知道。
如果跨線程發(fā)送消息，是會(huì)有一次拷貝，在C++11里可以用 move semantic 解決。  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-08-30 14:49 bertyoung

@陳碩
非常支持博主的分享精神；
我重點(diǎn)關(guān)注了博主對(duì)tcp發(fā)送數(shù)據(jù)的處理；
確實(shí)wakeup會(huì)調(diào)用多次；
另外eventfd的一對(duì)read/write操作，接近300W次/s(至強(qiáng)E5-2650)
感覺還是有點(diǎn)耗；
不知是否能從程序角度盡量減少這種為發(fā)數(shù)據(jù)所做的喚醒。
該問題我考慮了幾天，但結(jié)論僅僅是在tcpsocket注冊(cè)了EPOLLOUT時(shí)不需要喚醒，一旦數(shù)據(jù)發(fā)送完全，移除EPOLLOUT事件，每次發(fā)數(shù)據(jù)還是需要喚醒的

  回復(fù)  更多評(píng)論   

# re: 《Muduo 網(wǎng)絡(luò)庫：現(xiàn)代非阻塞C++網(wǎng)絡(luò)編程》演講 2012-08-30 15:09 Solstice

@bertyoung
真要在乎這個(gè)，就不要跨線程發(fā)送數(shù)據(jù)。當(dāng)前IO線程發(fā)送數(shù)據(jù)是不會(huì)wakeup的。  回復(fù)  更多評(píng)論