CppExplore

blessing

能得出上面的結(jié)論，可能有下面幾個原因：
1、在學(xué)會了數(shù)據(jù)結(jié)構(gòu)之后，至今還沒學(xué)會STL，至少對STL沒有全面的認(rèn)識
2、在復(fù)雜程序的數(shù)據(jù)結(jié)構(gòu)面前，不能靈活應(yīng)用學(xué)過的數(shù)據(jù)結(jié)構(gòu)的精髓：思想
3、尚未系統(tǒng)的學(xué)習(xí)c++庫
4、尚未寫過大型的應(yīng)用層程序
5、對哲學(xué)沒有深入的思考。看問題片面，主觀性強(qiáng)。

吾生也有涯,爾知也無涯。共勉！

無頭鏈表使用起來，問題多多。

面試官不夠?qū)捜荩嬖囌弑容^倔。峣峣者易折,佼佼者易污。共勉！
如果你是面試官，你會怎樣安排面試題目，如何在有限的時間里考察一個人呢？
如果你是面試者，你希望被如何面試，如何在有限的時間里展示自己的優(yōu)點(diǎn)呢？

@true
：）
這個就是文中2（1）的模型，主線程accept，將新的clientfd通過管道傳遞給epoll線程，管道的讀端也在epoll的監(jiān)控之下。不使用管道的話，sockpair也可以，不過它也是基于管道實(shí)現(xiàn)。
管道的連接是不可回避的，因?yàn)閑poll線程在epoll_wait處等待，要實(shí)時的告訴epoll監(jiān)控某fd，一定要epoll_wait返回，執(zhí)行加入操作，再繼續(xù)epoll_wait。
后面的業(yè)務(wù)線程處理也就是2（4）和2（5）模型。
2（3）是單線程的模型，就epoll而言，單線程的性能最好，也就是epoll+單線程=高性能。業(yè)務(wù)線程當(dāng)然是根據(jù)需要后接線程，測試的數(shù)據(jù)一直沒時間發(fā)出來，過幾天發(fā)下。

@true
可以在上一篇《網(wǎng)絡(luò)模型二》http://www.shnenglu.com/CppExplore/archive/2008/03/21/45061.html中跟貼討論新模型，是文中已有的，還是沒有的新模型，本文旨在討論函數(shù)本身的差異。
epoll和線程池的結(jié)合，不是很理解，是epoll單線程后接業(yè)務(wù)線程，還是epoll本身線程池？epoll本身的話，我想象不出來，結(jié)構(gòu)在可讀狀態(tài)的話，新線程epoll_wait還是可讀。并且線程池要求無內(nèi)蘊(yùn)狀態(tài)，行為的變化來自于外界的輸入?yún)?shù)，莫非是《網(wǎng)絡(luò)模型二》中的模型2（1）？
就epoll而言，《網(wǎng)絡(luò)模型二》的2模型中，業(yè)務(wù)線程先不談，單線程的epoll性能就很強(qiáng)，其他模型的測試結(jié)果反而有下降。poll/select則不同。
這個話題最好還是在《網(wǎng)絡(luò)模型二》中探討，本文不多擴(kuò)展。

removed!

@菌子
個人做過.net、java、c、c++的項(xiàng)目，談點(diǎn)個人的看法：net和java相比，想不出任何的優(yōu)勢來，跨平臺net不行，開源方面net不行，java社區(qū)的活力net更是不及，java幾乎可以統(tǒng)一企業(yè)級的上層應(yīng)用業(yè)務(wù)開發(fā)。
應(yīng)用服務(wù)器、游戲服務(wù)器、圖形方面還是c++的強(qiáng)項(xiàng)，性能、穩(wěn)定性、語言特性、低層庫的支持，其它語言還是難以競爭吧。追逐高性能、高并發(fā)高吞吐量的服務(wù)器領(lǐng)域，也不是java能與之競爭的。
個人做的c項(xiàng)目一樣可以換成c++來開發(fā)，c能勝任，c＋＋不能勝任的 可能就是c++編譯器不能觸及的地方吧，暫時想不出來。

歡迎 等你好文章啊

它使用Apache License。允許免費(fèi)修改重發(fā)布，允許商業(yè)使用，允許不公布修改后的源代碼。

/usr/include/sys/queue.h

@zoyi
紅黑樹就是二叉平衡樹的調(diào)整版本 std::map就可以作為實(shí)現(xiàn)用。
呵呵 有第一個就會有第二個、第三個........

能從二分過渡過去的，怎么也不應(yīng)該想到用hash啊，直接想到的也應(yīng)該是紅黑樹。主鍵是字符串除外

3個參數(shù)的是strncpy
就空間存儲而言，還是用memcpy類函數(shù)
另因?yàn)閟tring內(nèi)存布局的不透明性，用memcpy也是不明智的選擇，更遑論存儲空間的連續(xù)性問題了。
就strcpy而言，取string的c_str()一定是沒問題的。

mfc嚇退了一大批的程序員，帶壞了一大批程序員，害人不淺啊。

所有人共同努力的結(jié)果，最后有其中的一人整理成論文而已吧

removed by cppexpore

那里沒有我心目中的標(biāo)準(zhǔn)答案 遺憾啊 呵呵

HijackThis.exe

精彩！多多發(fā)點(diǎn)這種造福大眾的文章啊！

@Fox
呵呵，不同的經(jīng)驗(yàn)?zāi)艿贸霾煌目捶ā?
我覺得這種題目，查表法不僅不是“奇技淫巧”，反而是最完美的方法。

就像經(jīng)常見的面試題：給定一個unsigned char類型變量，輸出按位反轉(zhuǎn)后的值，比如0x2A=00101010 反轉(zhuǎn)后就是01010100=0x54

猜猜這個題目的標(biāo)準(zhǔn)答案是什么啊，呵呵，查表法。如果反對，請給出一個比這個還高效的算法。

最簡單的方法是先寫個效率低下的程序，把所有結(jié)果打印出來。
然后寫個程序，把結(jié)果存在一個表里，用查表法，掃描整個表，挨個打印出來。

當(dāng)然也可以一個變量不用，直接把上個程序的輸入結(jié)果，打印下。不過這樣就沒意義了。實(shí)際的應(yīng)用一定是需要其中的結(jié)果，而查表是最實(shí)用的。

果然夠草

好文，多寫點(diǎn)這種類型的。
工欲善其事，必先利其器

呵呵 再多寫幾個月就好了，也就是等寫到麻木就好了。

呵呵，以前寫c語言常用的方法。
c語言中，指針在結(jié)構(gòu)體里的使用，真是非常的精巧。

多謝提醒，2的問題還真是遺漏了，1的問題的確也應(yīng)該考慮，呵呵

附一個我實(shí)現(xiàn)的線程消息隊(duì)列：http://www.shnenglu.com/CppExplore/archive/2008/03/20/44949.html
消息類型的申請釋放配合小對象內(nèi)存池，完美的解決方案

既然是傳遞指針進(jìn)消息隊(duì)列，取端進(jìn)行free，想必是同一進(jìn)程間的通訊吧。
為什么要用ipc的消息隊(duì)列呢，很笨重，自己寫線程消息隊(duì)列性能更高，簡直不是一個數(shù)量級的。

贊一個，很系統(tǒng)，等待你的測試驅(qū)動開發(fā)方案的ppt，：）

嘿嘿，可以得分滴。不過刷新分?jǐn)?shù)有間隔的，并不是實(shí)時的。

期待中......
看來是一個更高一級的封裝，考慮的東西更多更復(fù)雜。公布出來一定拜讀。

公布的源碼放首頁好嗎？這個讓讀者看了沒什么收獲啊

@eXile
第三方庫中的定時器實(shí)現(xiàn)還沒看呢，以后有時間整理下。最近是不準(zhǔn)備研究了。

@kw
呵呵，想了下，真是不高啊。
直接保存gettimeoftime（）＋interval的時間做間隔，并在LIST中排序應(yīng)該是最好的方法。

@Colin
呵呵，你的精度要求太高了。零點(diǎn)了，該睡了。8888

@Colin
你可真快啊，我有個習(xí)慣：把寫的丟失，中途會提交，然后再修改再提交直到結(jié)束。最后寫完，就已經(jīng)有回復(fù)了，呵呵。
精度問題，只能在系統(tǒng)能力之內(nèi)盡量了，一般的應(yīng)用server非實(shí)時性很強(qiáng)的系統(tǒng)需要不了微秒級的精度，我的實(shí)際應(yīng)用秒級夠了。

@創(chuàng)
呵呵，不奇怪啊。我壓根就沒看stl的內(nèi)存池，ACE的看了，果然是集大成者，到是想寫呢，后來寫多了加上去寫其他方面的 就懶了。
現(xiàn)在網(wǎng)絡(luò)模型的也是寫了一半，下一篇估計(jì)就是去寫定時期了，呵呵

@創(chuàng)
你看的第一篇吧，對于小對象后面的loki和boost都不錯的。
不要浪費(fèi)精力研究了，就是一個結(jié)構(gòu)，原理都很簡單，看的太仔細(xì)了也是沒什么意思，呵呵。

http://www.shnenglu.com/CppExplore/archive/2008/02/18/42890.html
http://www.shnenglu.com/CppExplore/archive/2008/02/19/42952.html
http://www.shnenglu.com/CppExplore/archive/2008/02/20/42986.html

沒什么算法，結(jié)構(gòu)決定了算法。

系統(tǒng)調(diào)用不檢查返回值？系統(tǒng)沒有l(wèi)og機(jī)制？
監(jiān)控一個沖突一個的話，還有什么監(jiān)控的必要。
這些端口沒什么區(qū)別，linux上1024下的是預(yù)留端口，需要root帳號才能bind。
bind成功的標(biāo)志就是bind函數(shù)返回成功，呵呵。

@RichardHe
隨意 很寬松
至少要言之有物，讓別人看了有點(diǎn)收獲。
當(dāng)然個人的主觀偏見也是避免不了的。

呵呵，你還真執(zhí)著，又挪首頁來了，莫非是我上次移處失敗？

留言是這個：“文章《周二》移出1.首頁原創(chuàng)精華區(qū) ”。
多多理解、配合！

登陸后在你的后臺管理頁面有一個查看“留言”，那里面。

每天寫工作日志是個好習(xí)慣！
請關(guān)注下私人留言。

@suxiaojack
呵呵 一語中的！文中的內(nèi)容的確不是技巧，都是能優(yōu)雅解決實(shí)際問題的東東

@xushiwei
“它是基礎(chǔ)設(shè)施，那么它的性能調(diào)優(yōu)是非常關(guān)鍵的”，這句話我不反對，雖然我認(rèn)為對變長內(nèi)存池沒必要。不過你的測試代碼并沒有反映apr_pool的真實(shí)性能。

@ecopgm
這么晚還沒睡覺啊。
這里說的爆發(fā)的連接，也可以說是單點(diǎn)并發(fā)。你想的并發(fā)是不是同時在線的連接啊？一般都是追求的同時在線連接數(shù)。爆發(fā)連接的場景畢竟也不多。尤其是對音頻視頻等多媒體的應(yīng)用服務(wù)器，限于網(wǎng)絡(luò)帶寬，也不可能有爆發(fā)的連接出現(xiàn)，有的話直接拒絕連接就可以接受，呵呵。

@ecopgm
1、上面的模型并不是都將accept獨(dú)立處理啊？各種情況都有的。“下級線程池處理邏輯”這個就多說了，這個和accept/讀寫是否在同一線程不沖突，不同線程的時候也可以把邏輯獨(dú)立出來。各種模型性能上的數(shù)據(jù)對比后面的文章會給出具體的數(shù)據(jù)。概括說下，不單獨(dú)處理accept，除epoll方式外，爆發(fā)連接都會出現(xiàn)拒絕連接情況，比如ab（apache帶的工具）并發(fā)1w的時候。當(dāng)然并非所有的服務(wù)器能是要處理這種爆發(fā)的斷連接。在不拒絕連接的情況下，比如并發(fā)1000，性能還是差不多的。
2、連接被拒絕是在三路握手階段，accept接受的所有連接，連接就不會被丟掉了啊，生產(chǎn)者的確是非常快，消費(fèi)者很慢，但不影響client把數(shù)據(jù)發(fā)送到這邊的接受緩沖區(qū)。服務(wù)器沒有發(fā)送reset的必要，client也不會發(fā)fin分節(jié)，連接自然不會被丟掉。
3、消息隊(duì)列自然比管道快，這里的消息隊(duì)列不是ipc的消息隊(duì)列，全部實(shí)現(xiàn)在用戶態(tài)，可以看下上一篇《線程二》有消息隊(duì)列的實(shí)現(xiàn)，比涉及系統(tǒng)調(diào)用的管道快，管道怎么也是屬于進(jìn)程間通訊的方式。但是消息隊(duì)列不能象管道一樣把文件描述符放到fd_set里，供select監(jiān)控。