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