在學習muduo網路庫前，應該先熟悉一下多執行緒網路服務程式設計模型。在6.6.2節介紹了11種方案。方案0到方案4用的是阻塞i/o。方案5到方案11用的都是非阻塞i/o。
方案0：accept+read/write
方案0不是併發模型，只是乙個迴圈處理。用**表示的話，可以表示為：
while(true)
方案1accept+fork
這是個併發模型，這個模型比較簡單，在accept後，fork乙個子程序，在子程序處理連線。可以表示為：
while(true)
//parent
close(fd);
}
方案2accept+thread
這個方案和方案1類似，只是這個方案中是通過新建了執行緒來處理連線，方案1是通過新建執行緒來處理連線。
void processio(void* arg)
void processaccept()
}}
方案3prefork
這個和方案1類似，只是先建立好程序。當有連線到來時，可以馬上使用這些程序。具體可以參考
方案4pre thread
這和方案2類似，先建立好執行緒，等連線到來時，省去了建立執行緒的開銷。
方案5poll(reactor)
這個方案是基於i/o復用的select/poll/epoll；復用的是程序，不是i/o。這是乙個單執行緒/程序的方案，在i/o事件到達後，直接在當前執行緒/程序處理i/o。單執行緒/程序的reactor模式，在處理當前i/o事件時，如果有新的i/o事件到來，不能及時響應。這樣事件的優先順序不能得到保證。
方案6reactor+thread-per-task
這個方案是為每乙個i/o事件建立乙個執行緒，在新建的執行緒中處理i/o事件。注意，這裡是為每個i/o事件建立乙個執行緒，而不是為每個連線建立執行緒。這樣一來，每個新建執行緒處理的i/o事件的結果會有out-of-order的可能，即多次處理後的順序和請求順序未必一直了。
方案7reactor+worker thread
為了避免方案6中的out-of-order的問題，在這個方案中，為每個連線建立乙個執行緒。但是執行緒數目受限於cpu。
方案8reactor+thread pool
這個方案是，在reactor執行緒中，等待i/o事件，當i/o事件到來時，在thread pool中取出乙個執行緒（不是新建立）來處理i/o事件。
方案9reactors in threads
muduo和netty採用的是這種方案。在乙個main reactor中負責accept，之後把建立的連線fd放到sub reactor中，這個連線的所有操作都在sub reactor中完成。這個方案的特點是one loop per thread，有多個thread。
方案10reactors in process
這個是nginx的方案，連線之間無交換時，這是很好的解決方案。
方案11reactors+thread pool
這是方案8和方案9的混合體。即使用多個reactor,有的負責accept，有的負責i/o事件的到來。再使用執行緒池，處理i/o事件。
為什麼需要多執行緒程式設計模型
首先，我們需要多執行緒的主要原因是 在許多應用中會同時發生多種活動，某些活動會隨著時間的推移被阻塞，通過將這些應用程式分解成可以準並行執行的多個順序執行緒，程式設計模型會變得簡單起來。這裡可以說加入了乙個新的元素 並行實體共享同乙個位址空間和所有可用資料的能力。對於某些應用而言，這種能力是必須的，而...
為什麼需要多執行緒程式設計模型
首先，我們需要多執行緒的主要原因是 在許多應用中會同時發生多種活動，某些活動會隨著時間的推移被阻塞，通過將這些應用程式分解成可以準並行執行的多個順序執行緒，程式設計模型會變得簡單起來。這裡可以說加入了乙個新的元素 並行實體共享同乙個位址空間和所有可用資料的能力。對於某些應用而言，這種能力是必須的，而...
多執行緒伺服器 程式設計模型
多執行緒的價值在於發揮多核處理器的效能，單核使用狀態機是最高效的。提高平均響應時間 處理三個半事件 連線的建立 鏈結的斷開 訊息到達 訊息傳送完畢，對於低流量的服務不必關心 好處 執行緒數目基本固定，不會頻繁建立銷毀 可以方便地調配負載 io事件發生的執行緒固定，無需考慮併發。迭代伺服器 accep...