blessing

能得出上面的結論，可能有下面幾個原因：
1、在學會了數據結構之后，至今還沒學會STL，至少對STL沒有全面的認識
2、在復雜程序的數據結構面前，不能靈活應用學過的數據結構的精髓：思想
3、尚未系統的學習c++庫
4、尚未寫過大型的應用層程序
5、對哲學沒有深入的思考。看問題片面，主觀性強。

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

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

面試官不夠寬容，面試者比較倔。峣峣者易折,佼佼者易污。共勉！
如果你是面試官，你會怎樣安排面試題目，如何在有限的時間里考察一個人呢？
如果你是面試者，你希望被如何面試，如何在有限的時間里展示自己的優點呢？

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

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

removed!

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

歡迎 等你好文章啊

它使用Apache License。允許免費修改重發布，允許商業使用，允許不公布修改后的源代碼。

/usr/include/sys/queue.h

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

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

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

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

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

removed by cppexpore

那里沒有我心目中的標準答案 遺憾啊 呵呵

HijackThis.exe

精彩！多多發點這種造福大眾的文章啊！

@Fox
呵呵，不同的經驗能得出不同的看法。
我覺得這種題目，查表法不僅不是“奇技淫巧”，反而是最完美的方法。

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

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

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

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

果然夠草

不錯不錯！
思維很活躍，文筆也很好。

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

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

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

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

附一個我實現的線程消息隊列：http://m.shnenglu.com/CppExplore/archive/2008/03/20/44949.html
消息類型的申請釋放配合小對象內存池，完美的解決方案

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

贊一個，很系統，等待你的測試驅動開發方案的ppt，：）

嘿嘿，可以得分滴。不過刷新分數有間隔的，并不是實時的。

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

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

@eXile
第三方庫中的定時器實現還沒看呢，以后有時間整理下。最近是不準備研究了。

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

@Colin
呵呵，你的精度要求太高了。零點了，該睡了。8888

@Colin
你可真快啊，我有個習慣：把寫的丟失，中途會提交，然后再修改再提交直到結束。最后寫完，就已經有回復了，呵呵。
精度問題，只能在系統能力之內盡量了，一般的應用server非實時性很強的系統需要不了微秒級的精度，我的實際應用秒級夠了。

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

@創
你看的第一篇吧，對于小對象后面的loki和boost都不錯的。
不要浪費精力研究了，就是一個結構，原理都很簡單，看的太仔細了也是沒什么意思，呵呵。

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

沒什么算法，結構決定了算法。

系統調用不檢查返回值？系統沒有log機制？
監控一個沖突一個的話，還有什么監控的必要。
這些端口沒什么區別，linux上1024下的是預留端口，需要root帳號才能bind。
bind成功的標志就是bind函數返回成功，呵呵。

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

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

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

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

每天寫工作日志是個好習慣！
請關注下私人留言。

@suxiaojack
呵呵 一語中的！文中的內容的確不是技巧，都是能優雅解決實際問題的東東

@xushiwei
“它是基礎設施，那么它的性能調優是非常關鍵的”，這句話我不反對，雖然我認為對變長內存池沒必要。不過你的測試代碼并沒有反映apr_pool的真實性能。

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

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