@ian
把 CMakeLists.txt 中 -march=native 這句話去掉，重新編譯試試。
@天道酬勤
版本四，在你說(shuō)的情況下，根本不會(huì)去 wait()，因?yàn)?while 條件不滿足，因此不會(huì)丟信號(hào)。
@askforemore1018
在你說(shuō)的這種情況下，版本八有可能丟，版本四不可能丟，想想為什么。
@其實(shí)俺不是什么所謂的壞人
我文中寫(xiě)了“現(xiàn)在用 NULL 也能達(dá)到 nullptr 的好處，大不了在某個(gè)頭文件里define一下就行。”
不信在g++下試一下：
#include <stdio.h>
void foo(int)
{
printf("int");
}
void foo(char*)
{
printf("char*");
}
int main()
{
foo(NULL);
}
$ g++ null.cc
null.cc: In function 'int main()':
null.cc:15:11: error: call of overloaded 'foo(NULL)' is ambiguous
null.cc:15:11: note: candidates are:
null.cc:3:6: note: void foo(int)
null.cc:8:6: note: void foo(char*)
@zuhd
網(wǎng)上書(shū)店都是75折，不到70塊，還免運(yùn)費(fèi)。
@xxf
2. 直接用string，如果data中含有二進(jìn)制數(shù)據(jù)，如0，不是會(huì)丟失嗎，而且如果這個(gè)段data很長(zhǎng)，會(huì)發(fā)生一次數(shù)據(jù)拷貝吧？
有'\0'也不會(huì)丟失，你試試就知道。
如果跨線程發(fā)送消息，是會(huì)有一次拷貝，在C++11里可以用 move semantic 解決。
@唐詩(shī)
ConnectionEventHandler 和 DataEventHandler 二者的成員函數(shù)當(dāng)然不一樣，Connector 關(guān)心的是 writable event，Acceptor 關(guān)心的是 readable event。
說(shuō)到底你說(shuō)因?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
@楊軍
> 不過(guò)(void)n;這種類(lèi)似的語(yǔ)句也會(huì)帶來(lái)額外的代碼
Are you sure?
@楊軍
你試試去掉它，然后用
BUILD_TYPE=release ./build.sh
編譯。
@楊軍
你認(rèn)為 muduo 代碼中的 UINTPTR_MAX 的作用是什么？
https://gist.github.com/3059083
@楊軍
不改。你寫(xiě)個(gè)程序測(cè)一測(cè)吧。
@唐詩(shī)
改成 EventHandler 一樣是錯(cuò)的，is-a 關(guān)系必須滿足 Liskov 替換原則：
凡是程序里需要用到 EventHandler 的地方，換成它的任何一個(gè)派生類(lèi)都是可行的。
但是顯然 Acceptor、Connector 等等不具備這種可替換性。
@唐詩(shī)
除了我前面給的鏈接里那篇文章里給的原因，
更重要的理由就是：我認(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ù)用。
@唐詩(shī)
你的意思是說(shuō)：
Acceptor is-a Channel
Connector is-a Channel
EventLoop is-a Channel
TcpConnection is-a Channel
TimerQueue is-a Channel
像這樣建模？
OO 中毒太深了吧？
@唐詩(shī)
如果把Channel class設(shè)計(jì)成虛函數(shù)接口，那么在下面這五處用到Channel事件回調(diào)的地方，要么各自派生一個(gè) inner DerivedChannel class，要么他們都直接繼承Channel，兩種做法問(wèn)題都更大。
Acceptor::acceptChannel_
Connector::channel_
EventLoop::wakeupChannel_
TcpConnection::channel_
TimerQueue::timerfdChannel_
另見(jiàn)：muduo.chenshuo.com/2012/07/modern-c-api-in-muduo-part-1.html
@楊軍
每次調(diào)用多了N+1次內(nèi)存分配和釋放的開(kāi)銷(xiāo)，好處是什么？節(jié)約了一個(gè) tls 變量？
你要認(rèn)為這是值得的，那就這樣寫(xiě)唄。
@楊軍
1. namelist 沒(méi)有釋放。
2. 每次調(diào)用都要分配釋放內(nèi)存，增加開(kāi)銷(xiāo)。
@楊軍
我測(cè)過(guò)，atexit() 處理500個(gè)Singleton沒(méi)有問(wèn)題。
sysconf(_SC_ATEXIT_MAX) 的返回值足夠大。
@楊軍
assert(namelist == NULL);
不需要釋放。
@test
那你怎么關(guān)閉那個(gè) pending connection ？
抑或根本不是 level-trigger reactor？
@test
這位名為“test”的網(wǎng)友，您測(cè)過(guò)嗎？
@ouyang
按照你提供的數(shù)據(jù)，并發(fā)數(shù) 30000，每個(gè)連接存活時(shí)間 10 秒，可以計(jì)算出至少每秒鐘要 accept 3000 個(gè)連接，并斷開(kāi) 3000 個(gè)舊連接（假設(shè)客戶端主動(dòng)斷開(kāi)連接，這樣服務(wù)器不進(jìn)入 time-wait 狀態(tài)）。
對(duì)于服務(wù)端，每 accept 一個(gè)連接需要收兩個(gè) packet，發(fā)一個(gè) packet。
每斷開(kāi)一個(gè)連接需要收兩個(gè) packet，發(fā)兩個(gè) packet。
這樣一生一滅，操作系統(tǒng)每秒鐘要處理 6~7 * 3000 = 18,000 ~ 21,000 個(gè) packet。你確定你的服務(wù)器還有資源處理業(yè)務(wù)嗎？
如果是單線程，平均每個(gè)連接的業(yè)務(wù)處理時(shí)間只有 0.3 毫秒，來(lái)得及完成任務(wù)嗎？
對(duì)于 muduo，需要做的優(yōu)化是修改 Acceptor::handleRead()，每次 accept N 個(gè)連接，而不是 1 個(gè)。N 的值可能是 10。
見(jiàn)下面這篇論文第 5.2 節(jié)：
http://www.cs.uwaterloo.ca/~brecht/papers/ols-2004.pdf
@楊粼波
思考題：為什么 muduo::net::Buffer 不需要 reserve()？
@ouyang
> 限制最大并發(fā)連接數(shù)為多少合適呢？
看應(yīng)用的復(fù)雜度，看多少個(gè)并發(fā)連接就把 CPU 或者 Memory 或者 IO 占滿，然后設(shè)一個(gè)比它略小的上限，以保證服務(wù)質(zhì)量。
> Muduo是否適合用來(lái)開(kāi)發(fā)大并發(fā)（單機(jī)2萬(wàn)+）、短連接、小流量（整體網(wǎng)絡(luò)流量不大）的TCP服務(wù)器？
應(yīng)該可以，可能要為短連接適當(dāng)優(yōu)化一下 Acceptor。不過(guò)如果是短連接的話，單機(jī)并發(fā) 2萬(wàn)+ 是指什么？同時(shí)有 2 萬(wàn)個(gè)連接在線嗎？那這不是長(zhǎng)連接嗎？
@路人甲
確實(shí)，output buffer 不必是連續(xù)的，反正復(fù)雜性丟給 TcpConnection 唄，可以用 writev 來(lái)減少系統(tǒng)調(diào)用次數(shù)。
@楊粼波
“調(diào)用reserve()才會(huì)預(yù)分配內(nèi)存”？！這是哪家的 STL？
我原文說(shuō)了，“vector 的 capacity() 以指數(shù)方式增長(zhǎng)，讓 push_back() 的平均復(fù)雜度是常數(shù)。”
如果“調(diào)用reserve()才會(huì)預(yù)分配內(nèi)存”如何達(dá)到 push_back 的平均復(fù)雜度要求？
幾行代碼就能驗(yàn)證的事情：
vector<char> vec;
printf("%zd %zd\n", vec.size(), vec.capacity());
vec.resize(1024);
printf("%zd %zd\n", vec.size(), vec.capacity());
vec.resize(1300);
printf("%zd %zd\n", vec.size(), vec.capacity());
運(yùn)行結(jié)果：
0 0
1024 1024
1300 2048
原話奉還：“自己先好好學(xué)一學(xué)STL。這些都是STL的內(nèi)存分配機(jī)制的問(wèn)題。
自己先多學(xué)點(diǎn)東西吧。”
@regexp
局域網(wǎng)內(nèi) NTP 校準(zhǔn)的準(zhǔn)確度是多少微秒？
局域網(wǎng)內(nèi)的 latency 是多少微秒？
這樣直接測(cè)試的結(jié)果有意義嗎？
@zuhd
Live Writer 和 gpic。
畫(huà)圖一天，碼字一天。
@陳梓瀚(vczh)
1. 我的這兩篇文章跟“編譯器版本”或“編譯器升級(jí)”有任何關(guān)系嗎？所有庫(kù)和可執(zhí)行文件都應(yīng)該用相同的編譯器版本來(lái) build，不影響文章的觀點(diǎn)。
2. 這兩篇文章主要是從庫(kù)的作者的角度來(lái)談，庫(kù)的作者和應(yīng)用程序的作者是兩個(gè)人群。如果要求每個(gè)應(yīng)用程序都自己編譯所用的動(dòng)態(tài)庫(kù)，那么這屬于我說(shuō)的“源代碼發(fā)布”，和靜態(tài)發(fā)布是一樣的，也不用怎么考慮二進(jìn)制兼容性，只要應(yīng)用程序做好 full build 就行。
3. extern "C" 跟本文有什么關(guān)系？動(dòng)態(tài)庫(kù)必須以 extern "C" 來(lái)提供接口？
@yrj
請(qǐng)先定義“本質(zhì)”，explicit 與 implicit 算不算本質(zhì)？
@violet
你的意思是
string name;
string address;
比
string name, address;
要難看？
@vczh
不是偷不偷懶的問(wèn)題。假設(shè)你是一個(gè) shared library 的維護(hù)者，你的 library 被另外兩三個(gè)團(tuán)隊(duì)使用了。你發(fā)現(xiàn)了一個(gè)安全漏洞，或者某個(gè)會(huì)導(dǎo)致 crash 的 bug 需要修復(fù)，那么你修復(fù)之后，能不能直接部署 library 的二進(jìn)制文件？有沒(méi)有破壞二進(jìn)制兼容性？會(huì)不會(huì)破壞別人團(tuán)隊(duì)已經(jīng)編譯好的投入使用的可執(zhí)行文件？是不是要強(qiáng)迫別的團(tuán)隊(duì)重新編譯鏈接，把可執(zhí)行文件也發(fā)布新版本？會(huì)不會(huì)打亂別人的 release cycle？這些都是工程開(kāi)發(fā)中應(yīng)該考慮的問(wèn)題。
@classyk
這個(gè)好吧，用縮進(jìn)。注釋函數(shù)的時(shí)候把 // 放第一列，注釋 for 循環(huán)的時(shí)候把 // 與 for 上面一行語(yǔ)句對(duì)齊。
@boquan
是在自己的測(cè)試程序中實(shí)現(xiàn)相應(yīng)的統(tǒng)計(jì)功能.
@imjj
希望看到 client 端的 ACE 實(shí)現(xiàn)。
@cpp
vector 能伸縮唄，適合不定長(zhǎng)的消息。
@chaogu
這是典型的 busy-waiting，建議改為：
19 pthread_mutex_lock(&mutex);
20 shareQuueue.push(shareObject);
++ pthread_cond_signal(&condvar);
21 pthread_mutex_unlock(&mutex);
30 pthread_mutex_lock(&mutex);
31 while (shareQueue.size() < 1){
++ pthread_cond_wait(&condvar, &mutex);
34 }
35 shareObject = shareQueue.pop();
36 pthread_mutex_unlock(&mutex);
參考：
http://github.com/chenshuo/recipes/blob/master/thread/BlockingQueue.h
@chaogu
循環(huán)體內(nèi)有沒(méi)有 pthread_cond_wait ? 或者貼一下代碼骨架吧。