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

陳碩的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的內存分配機制的問題。
自己先多學點東西吧?!?br>
@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年9月>
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

導航

統計

常用鏈接

隨筆分類

隨筆檔案

相冊

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            国产一区成人| 久久久久国内| 久久夜色精品| 久久综合网色—综合色88| 免费成人你懂的| 欧美激情在线狂野欧美精品| 亚洲人成在线免费观看| 亚洲国产一区在线| 日韩视频欧美视频| 亚洲免费在线精品一区| 久久久五月天| 欧美喷水视频| 国产日韩一区二区三区在线| 黄色资源网久久资源365| 亚洲欧洲精品一区二区三区 | 国产真实乱偷精品视频免| 狠狠色狠狠色综合人人| 久久综合精品一区| 欧美屁股在线| 国产喷白浆一区二区三区| 136国产福利精品导航网址| 一区二区三区毛片| 久久久久久久尹人综合网亚洲| 欧美国产日韩一区二区三区| 亚洲图片欧洲图片日韩av| 久久国产精品网站| 亚洲欧美激情诱惑| 欧美在线视频在线播放完整版免费观看| 国产精品v亚洲精品v日韩精品 | 狠狠色狠狠色综合日日五| 亚洲欧洲三级| 久久精品99久久香蕉国产色戒| 欧美国产三级| 久久激情五月丁香伊人| 欧美色精品天天在线观看视频 | 亚洲第一福利社区| 午夜精品影院| 99精品视频免费| 欧美sm重口味系列视频在线观看| 国产精品系列在线| 9l国产精品久久久久麻豆| 麻豆精品精品国产自在97香蕉| 亚洲一二区在线| 欧美精品一区三区在线观看| 在线观看久久av| 久久久噜噜噜久久久| 亚洲已满18点击进入久久| 欧美三级乱码| 亚洲视频在线视频| 亚洲精选在线| 欧美日韩一区二区三区在线观看免| 在线日韩中文| 蜜臀av国产精品久久久久| 久久久久国产精品厨房| 国产一区二区三区视频在线观看| 午夜精品偷拍| 亚洲一区二区不卡免费| 国产精品乱码人人做人人爱| 午夜精彩视频在线观看不卡| 亚洲一区二区视频| 国产精品影音先锋| 欧美在线播放一区二区| 亚洲免费人成在线视频观看| 国产精品一区免费在线观看| 欧美一区亚洲一区| 午夜在线观看欧美| 激情久久五月| 久热精品视频在线观看| 亚洲一区免费网站| 国产精品欧美日韩| 欧美在线视频日韩| 亚洲欧美在线网| 韩日欧美一区二区| 欧美电影免费观看| 欧美高清视频一区二区| 一区二区欧美激情| 亚洲欧美日韩爽爽影院| 怡红院av一区二区三区| 亚洲国产精品欧美一二99| 欧美日韩国产首页在线观看| 午夜精品久久久久久99热| 午夜精品视频一区| 亚洲成人在线| 一本到12不卡视频在线dvd| 国产精品亚洲不卡a| 美国成人直播| 欧美三级精品| 欧美成人第一页| 国产精品草草| 男人的天堂成人在线| 欧美日韩激情网| 久久精品夜色噜噜亚洲aⅴ| 免费日韩成人| 欧美亚洲综合在线| 欧美成人国产| 欧美在线观看网址综合| 免费在线亚洲| 久久gogo国模裸体人体| 欧美大片免费久久精品三p | 久久精品在线播放| 欧美激情一区二区三级高清视频| 亚洲一区二区三区精品在线观看| 欧美在线视频导航| 一区二区电影免费在线观看| 欧美中文字幕视频| 亚洲一区在线视频| 欧美精品乱人伦久久久久久| 久久精品亚洲一区| 欧美吻胸吃奶大尺度电影| 欧美**字幕| 国产亚洲制服色| 一本色道久久综合亚洲精品按摩| 韩国三级电影久久久久久| 亚洲图片欧美一区| 在线午夜精品自拍| 欧美不卡视频一区| 嫩草成人www欧美| 国产一区二区三区在线观看网站 | 一区二区三区www| 久久久久se| 久久久国产91| 国产一区二区三区高清| 亚洲少妇在线| 亚洲一区二区黄色| 欧美视频一区二区三区…| 亚洲高清视频一区| 亚洲欧洲三级电影| 久热精品视频在线免费观看| 欧美成人嫩草网站| 久久精品色图| 精品成人在线视频| 亚洲欧美资源在线| 性做久久久久久久免费看| 欧美日韩视频一区二区| 亚洲经典三级| 夜夜精品视频| 欧美日韩中文字幕在线| 亚洲国产精品一区二区第一页 | 免费永久网站黄欧美| 国外成人免费视频| 久久精品一二三区| 美国十次了思思久久精品导航| 黄色亚洲网站| 久久亚洲欧洲| 亚洲经典在线| 亚洲欧美日韩系列| 国产乱理伦片在线观看夜一区| 亚洲自拍偷拍网址| 久久天天狠狠| 最新日韩在线| 欧美日韩一区二区视频在线观看| 9久草视频在线视频精品| 亚洲欧美精品在线观看| 国产亚洲毛片| 欧美福利视频网站| 在线亚洲欧美| 久久久久久久网| 亚洲精品久久| 国产精品电影在线观看| 久久爱www.| 亚洲黄色高清| 西西裸体人体做爰大胆久久久| 国内精品久久久久久久果冻传媒| 噜噜噜躁狠狠躁狠狠精品视频| 亚洲区在线播放| 欧美一区二区三区在线看| 一区在线电影| 国产精品高潮呻吟| 蜜臀91精品一区二区三区| 亚洲特级毛片| 亚洲高清不卡在线| 久久国产精品电影| 中文日韩在线| 亚洲成色777777女色窝| 国产精品日日摸夜夜添夜夜av| 裸体女人亚洲精品一区| 亚洲一区免费| 亚洲激情小视频| 久久久久女教师免费一区| 99国产精品国产精品久久| 国产一区二区三区久久| 欧美精品久久久久a| 久久精品30| 亚洲视频免费在线| 91久久香蕉国产日韩欧美9色| 久久久午夜精品| 亚洲欧美综合v| 亚洲美女中文字幕| 亚洲第一综合天堂另类专| 国产日韩精品一区| 国产精品高潮视频| 欧美乱大交xxxxx| 老司机午夜精品视频| 欧美在线观看一二区| 亚洲一区二区三| 中文国产成人精品久久一| 亚洲精品视频一区二区三区| 欧美jjzz| 亚洲丁香婷深爱综合| 亚洲人成网站在线播|