2.在工作執行緒中呼叫printf會出現列印兩次的情況，這個不算問題，主要是因為工程的c執行時庫不是多執行緒版本，將工程設定為支援multithreaded就行了。
3.套接字資源**的問題。對方如果斷開了連線，也關閉了套接字，本地也檢測到對方關閉了連線，但這並不意味著套接字資源已經釋放掉了，還必須呼叫closesocket才能釋放連線所占有的套接字資源，也就是這個套接字id可以被accept函式重新利用了（當然，acceptex那種套接字池一類的模式並不需要closesocket，而是一種更節約的重利用規則，好處自然是不必說了。）
4.重疊和非同步。本人認為這兩者的區別還是很明顯的，非同步範圍太廣大的，重疊必然非同步，非同步的未必都是重疊的，言至此，下面就不知道說些什麼了。
6.關於心跳檢測，本人認為，底層iocp設計不應該考慮這個問題，考慮這個問題的應該是上層應用，是在閘道器伺服器裡面做檢測還是在發言廣播伺服器裡面檢測完全可以視情況而定，如果非要在iocp封裝類裡面提供心跳檢測模組，那還得搞乙個開關，需要開啟的時候才開啟檢測，總不能乙個網路遊戲集群伺服器組，地圖伺服器也心跳檢測，登入伺服器也檢測……
7.關於記憶體池。記憶體池這東西還真是讓人不知道說什麼好，成熟的產品有不少，很多人也動手寫過，效率怎麼樣，寫過的人也都心知肚明，反正本人寫的記憶體池是不太行。拋開效率不談，儲存資源節約問題才是選擇記憶體池的關鍵，不過，還是希望用一些成熟的產品。linux下好用的記憶體池有不少，windows下嘛，高版本的vs可享有幾個好產品，vc6.0這種古董級編譯器，貌似就沒有什麼好的選擇了。本人要求不高，windows記憶體池，支援多執行緒，但起碼也得用head-tail鎖的，簡單的臨界區……不行！
8.iocp工作執行緒獲取資料以後，到底該如何分發處理？資料處理執行緒是必須要有的，問題是是不是所有資料處理都得通過佇列交給資料處理執行緒。本人想，不十分耗時的操作就在工作執行緒中解決，耗時的操作再投遞到佇列中，畢竟，佇列操作一般是要加鎖的。
9.是否需要fifo佇列？如果乙個工作執行緒對應乙個佇列的話，那麼fifo佇列是必然的選擇，嗯，求穩定好用的fifo佇列，有的吼一聲啊。
。。。其他問題，以後發現了再提出來
IOCP的一些總結
1 在iocp中投遞wsasend返回wsa io pending的時候，表示非同步投遞已經成功，但是稍後傳送才會完成。這其中涉及到了三個緩衝區。網絡卡緩衝區，tcp ip層緩衝區，程式緩衝區。情況一 呼叫wsasend傳送正確的時候 即立即返回，且沒有錯誤 tcp ip將資料從程式緩衝區中拷貝到t...
IOCP的一些心得
iocp的工作執行緒的個數一般設定為processors 2 2，這是綜合考慮了工作執行緒可能是等待 掛起 正在執行的狀態。如果你測試出更好的結果，以你的為標準。iocp的工作執行緒由系統排程和優化，不要去干預執行緒的排程，除非你自信能超越系統的排程。在遇到奇怪的問題時，可以嘗試減少iocp工作執行...
QT Creator 中一些要注意的地方
5.3 拖放操作 1.執行程式，拖放的時候要拖放到主視窗上，而不是text edit部件上，否則只顯示檔案路徑，而不是檔案內容 2.拖放的時候，會顯示中文亂碼 修改一下讀取檔案的處理函式 void mainwindow dropevent qdropevent event 對於中文顯示亂碼用一行處理...