青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

陳碩的Blog

共2頁: 1 2 
@ian
把 CMakeLists.txt 中 -march=native 這句話去掉,重新編譯試試。
@lys86_1205
你可以先單步跟蹤一下。
@ 天道酬勤
你想說啥?
@天道酬勤
版本四,在你說的情況下,根本不會去 wait(),因為 while 條件不滿足,因此不會丟信號。
@askforemore1018
在你說的這種情況下,版本八有可能丟,版本四不可能丟,想想為什么。
@其實俺不是什么所謂的壞人
我文中寫了“現在用 NULL 也能達到 nullptr 的好處,大不了在某個頭文件里define一下就行?!?br>
不信在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
網上書店都是75折,不到70塊,還免運費。
@xxf
2. 直接用string,如果data中含有二進制數據,如0,不是會丟失嗎,而且如果這個段data很長,會發生一次數據拷貝吧?

有'\0'也不會丟失,你試試就知道。
如果跨線程發送消息,是會有一次拷貝,在C++11里可以用 move semantic 解決。
@唐詩
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
@楊軍
> 不過(void)n;這種類似的語句也會帶來額外的代碼

Are you sure?
@楊軍
你試試去掉它,然后用
BUILD_TYPE=release ./build.sh
編譯。
@楊軍
你認為 muduo 代碼中的 UINTPTR_MAX 的作用是什么?
https://gist.github.com/3059083
@楊軍
不改。你寫個程序測一測吧。
@唐詩
改成 EventHandler 一樣是錯的,is-a 關系必須滿足 Liskov 替換原則:
凡是程序里需要用到 EventHandler 的地方,換成它的任何一個派生類都是可行的。
但是顯然 Acceptor、Connector 等等不具備這種可替換性。
@唐詩
除了我前面給的鏈接里那篇文章里給的原因,
更重要的理由就是:我認為這么建模是錯的。
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-a Channel
Connector is-a Channel
EventLoop is-a Channel
TcpConnection is-a Channel
TimerQueue is-a Channel
像這樣建模?
OO 中毒太深了吧?
@楊軍
謝謝,會在下一版修正。
@唐詩
如果把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
@楊軍
每次調用多了N+1次內存分配和釋放的開銷,好處是什么?節約了一個 tls 變量?
你要認為這是值得的,那就這樣寫唄。
@楊軍
1. namelist 沒有釋放。
2. 每次調用都要分配釋放內存,增加開銷。
@楊軍
寫一個來看看?
@楊軍
For thread safety.
@楊軍
我測過,atexit() 處理500個Singleton沒有問題。
sysconf(_SC_ATEXIT_MAX) 的返回值足夠大。
@楊軍
assert(namelist == NULL);
不需要釋放。
@lijsf
UDP ?!
@ISO
佩服佩服!
@tfzxyinhao
有此計劃。
@test
那你怎么關閉那個 pending connection ?
抑或根本不是 level-trigger reactor?
@test
這位名為“test”的網友,您測過嗎?
@ouyang
按照你提供的數據,并發數 30000,每個連接存活時間 10 秒,可以計算出至少每秒鐘要 accept 3000 個連接,并斷開 3000 個舊連接(假設客戶端主動斷開連接,這樣服務器不進入 time-wait 狀態)。
對于服務端,每 accept 一個連接需要收兩個 packet,發一個 packet。
每斷開一個連接需要收兩個 packet,發兩個 packet。
這樣一生一滅,操作系統每秒鐘要處理 6~7 * 3000 = 18,000 ~ 21,000 個 packet。你確定你的服務器還有資源處理業務嗎?
如果是單線程,平均每個連接的業務處理時間只有 0.3 毫秒,來得及完成任務嗎?

對于 muduo,需要做的優化是修改 Acceptor::handleRead(),每次 accept N 個連接,而不是 1 個。N 的值可能是 10。
見下面這篇論文第 5.2 節: http://www.cs.uwaterloo.ca/~brecht/papers/ols-2004.pdf
@楊粼波
思考題:為什么 muduo::net::Buffer 不需要 reserve()?
@ouyang
> 限制最大并發連接數為多少合適呢?
看應用的復雜度,看多少個并發連接就把 CPU 或者 Memory 或者 IO 占滿,然后設一個比它略小的上限,以保證服務質量。

> Muduo是否適合用來開發大并發(單機2萬+)、短連接、小流量(整體網絡流量不大)的TCP服務器?
應該可以,可能要為短連接適當優化一下 Acceptor。不過如果是短連接的話,單機并發 2萬+ 是指什么?同時有 2 萬個連接在線嗎?那這不是長連接嗎?
@路人甲
確實,output buffer 不必是連續的,反正復雜性丟給 TcpConnection 唄,可以用 writev 來減少系統調用次數。
@楊粼波
“調用reserve()才會預分配內存”?!這是哪家的 STL?
我原文說了,“vector 的 capacity() 以指數方式增長,讓 push_back() 的平均復雜度是常數。”
如果“調用reserve()才會預分配內存”如何達到 push_back 的平均復雜度要求?

幾行代碼就能驗證的事情:

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());

運行結果:

0 0
1024 1024
1300 2048


原話奉還:“自己先好好學一學STL。這些都是STL的內存分配機制的問題。
自己先多學點東西吧。”
@regexp
局域網內 NTP 校準的準確度是多少微秒?
局域網內的 latency 是多少微秒?
這樣直接測試的結果有意義嗎?
@zuhd
Live Writer 和 gpic。
畫圖一天,碼字一天。
@陳梓瀚(vczh)
1. 我的這兩篇文章跟“編譯器版本”或“編譯器升級”有任何關系嗎?所有庫和可執行文件都應該用相同的編譯器版本來 build,不影響文章的觀點。
2. 這兩篇文章主要是從庫的作者的角度來談,庫的作者和應用程序的作者是兩個人群。如果要求每個應用程序都自己編譯所用的動態庫,那么這屬于我說的“源代碼發布”,和靜態發布是一樣的,也不用怎么考慮二進制兼容性,只要應用程序做好 full build 就行。
3. extern "C" 跟本文有什么關系?動態庫必須以 extern "C" 來提供接口?
@yrj
請先定義“本質”,explicit 與 implicit 算不算本質?
@violet
你的意思是
string name;
string address;

string name, address;
要難看?
@vczh
不是偷不偷懶的問題。假設你是一個 shared library 的維護者,你的 library 被另外兩三個團隊使用了。你發現了一個安全漏洞,或者某個會導致 crash 的 bug 需要修復,那么你修復之后,能不能直接部署 library 的二進制文件?有沒有破壞二進制兼容性?會不會破壞別人團隊已經編譯好的投入使用的可執行文件?是不是要強迫別的團隊重新編譯鏈接,把可執行文件也發布新版本?會不會打亂別人的 release cycle?這些都是工程開發中應該考慮的問題。
@classyk
這個好吧,用縮進。注釋函數的時候把 // 放第一列,注釋 for 循環的時候把 // 與 for 上面一行語句對齊。
@boquan
是在自己的測試程序中實現相應的統計功能.
@imjj
希望看到 client 端的 ACE 實現。
@ppx
Excel 2007 家庭版
@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
循環體內有沒有 pthread_cond_wait ? 或者貼一下代碼骨架吧。
@chaogu
Linux 上用什么方式等待?
共2頁: 1 2 
<2025年11月>
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

導航

統計

常用鏈接

隨筆分類

隨筆檔案

相冊

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            欧美wwwwww| 欧美激情一区在线| 国产日韩精品在线播放| 亚洲欧美色婷婷| 国产精品99久久久久久白浆小说| 欧美精品入口| 亚洲欧美日韩天堂| 亚洲综合导航| 狠狠噜噜久久| 亚洲国产欧美久久| 欧美国产日韩一区二区在线观看| 亚洲国产黄色| 日韩视频精品| 国产一区二区按摩在线观看| 久久亚洲影院| 欧美成人福利视频| 亚洲一区一卡| 久久久精品久久久久| 亚洲丁香婷深爱综合| 亚洲精品视频二区| 国产精品一区二区久激情瑜伽| 久久久av网站| 欧美极品在线播放| 欧美一区二区三区视频在线 | 免费看av成人| 欧美日韩1区| 久久精品一级爱片| 欧美aa国产视频| 午夜欧美电影在线观看| 久久久久se| 亚洲一区二区不卡免费| 欧美影院成年免费版| 亚洲精品久久嫩草网站秘色| 一本久道久久综合中文字幕| 国产亚洲一区二区三区| 亚洲经典在线| 国内精品视频在线观看| 亚洲乱码日产精品bd| 国产亚洲精品v| 一区二区三区国产精华| 亚洲大片免费看| 亚洲永久免费精品| 日韩午夜激情电影| 久久尤物电影视频在线观看| 亚洲午夜女主播在线直播| 久久久精品999| 午夜欧美大尺度福利影院在线看| 麻豆91精品| 久久久久久久波多野高潮日日 | 久久精品国产69国产精品亚洲| 亚洲伦理精品| 美女主播一区| 噜噜噜噜噜久久久久久91| 国产精品久久久久久亚洲调教| 亚洲国产va精品久久久不卡综合| 国产欧美短视频| 亚洲视频精品| 亚洲视频一区| 欧美日韩国产不卡| 亚洲激情另类| 亚洲国内精品| 欧美成人资源网| 欧美激情二区三区| 亚洲电影免费观看高清完整版在线 | 尤物视频一区二区| 欧美一区二区三区四区高清| 亚洲一区亚洲二区| 国产精品久久久久999| 日韩亚洲视频在线| 亚洲一区二区三区在线看| 欧美精品三级| 一本久道久久久| 亚洲欧美日韩在线综合| 国产精品久久久久久久久借妻| 日韩亚洲欧美一区二区三区| 一区二区三区四区蜜桃| 欧美日韩午夜| 亚洲午夜免费视频| 亚洲一级一区| 国产精品欧美激情| 性色av香蕉一区二区| 久久岛国电影| 亚洲成人自拍视频| 免费亚洲视频| 99视频+国产日韩欧美| 亚洲欧美日韩在线综合| 国产嫩草影院久久久久| 午夜在线观看免费一区| 久久先锋资源| 99av国产精品欲麻豆| 欧美特黄一级| 久久se精品一区二区| 欧美激情第三页| 亚洲视频一区二区| 国产噜噜噜噜噜久久久久久久久| 久久国产精品免费一区| 亚洲韩国精品一区| 亚洲欧美日韩国产一区二区| 国产午夜精品美女视频明星a级| 久久久久久噜噜噜久久久精品 | 欧美在线www| 欲色影视综合吧| 欧美日本韩国| 久久成人免费网| 亚洲精品四区| 久久综合国产精品| 亚洲视频一区| 在线成人免费视频| 国产精品大全| 欧美暴力喷水在线| 欧美一区二区三区免费看 | 亚洲一区久久久| 国外精品视频| 欧美激情日韩| 亚洲午夜在线视频| 亚洲国产精品电影| 性刺激综合网| 亚洲激情自拍| 国产精品视频专区| 亚洲天堂成人在线观看| 欧美国产精品久久| 亚洲综合精品四区| 一区二区三区在线观看视频| 欧美激情一区二区在线| 亚洲激情视频在线播放| 美女久久一区| 亚洲午夜电影在线观看| 伊人色综合久久天天| 欧美日韩成人在线| 久久精品综合| 欧美一区二区免费| 日韩一级免费观看| 欧美mv日韩mv国产网站| 亚洲午夜一区二区三区| 亚洲黄网站黄| 亚洲国产精品999| 国产精品少妇自拍| 欧美极品一区二区三区| 欧美在线综合视频| 中国成人黄色视屏| 免费视频一区| 久久青青草综合| 午夜精品久久久久久久久| 亚洲日本国产| 亚洲电影天堂av| 国产精品一区二区你懂得| 欧美精品日韩综合在线| 久久久久久久欧美精品| 欧美亚洲免费高清在线观看| 日韩一级二级三级| 一本久久精品一区二区| 亚洲高清在线| 欧美成va人片在线观看| 久久久国产一区二区三区| 香蕉视频成人在线观看 | 国产精品日韩在线播放| 欧美日本国产| 欧美国产成人精品| 久久精品国产亚洲aⅴ| 久久久夜色精品亚洲| 欧美一区国产一区| 欧美在线视频全部完| 亚洲一区3d动漫同人无遮挡| 亚洲一区二区欧美日韩| 一本久久青青| 夜夜嗨av色综合久久久综合网| 最新成人av在线| 一区二区三区精品视频| 一区二区三区精密机械公司| 日韩亚洲在线| 亚洲无线观看| 欧美一级专区| 欧美激情网友自拍| 欧美日韩大片| 国产精品视频免费一区| 国产三级欧美三级| 亚洲激情电影在线| 99re在线精品| 亚洲欧美视频在线| 欧美成ee人免费视频| 亚洲高清视频一区| 99精品国产高清一区二区| 亚洲午夜激情网站| 亚洲欧美日韩一区二区| 免费的成人av| 国产精品va在线| 国外成人性视频| 亚洲精品一区二| 久久久久久久久久久久久女国产乱| 久久色中文字幕| 亚洲第一区色| 亚洲无吗在线| 欧美大片一区二区| 国产精品国内视频| 禁断一区二区三区在线| 99re国产精品| 欧美中文字幕视频在线观看| 美玉足脚交一区二区三区图片| 亚洲国产影院| 午夜精品亚洲|