本文出處：
http://blog.csdn.net/sodme聲明：本文可以不經(jīng)作者同意任意轉載、復制、傳播，但任何對本文的引用均須保留本文的作者、出處及本行聲明信息！謝謝！
前言:?
錯誤處理和socket釋放, 是IOCP編程中的一大難點. 本文試圖就IOCP設計中經(jīng)常遇到的這個難題展開論述并尋找其解決方案, 事實上, 文中所述的解決方式不僅僅適用于IOCP, 它同樣適用于EPOLL等多種服務器編程的網(wǎng)絡模型中, 前提是: 領會這種處理方式的實質.
正文:
在使用IOCP開發(fā)時, 大家經(jīng)常遇到的一個難題是與socket相關的緩沖區(qū)釋放不當帶來的錯誤, 這種錯誤通常是由于多次對同一個指針執(zhí)行了delete操作引起的. 比如, 當在執(zhí)行wsasend或wsarecv返回了非pending的錯誤信息時, 我們就要對此錯誤進行處理, 通常情況下, 我們會想到執(zhí)行這兩步操作:
a. 釋放此次操作使用的緩沖區(qū)數(shù)據(jù)(如果不釋放可能造成內存泄漏);
b. 關閉當前操作所使用的socket.
而另一方面, 我們可能也會在get函數(shù)(GetQueuedCompletionStatus)的處理中, 當get函數(shù)返回值為FALSE時也作這兩步相同的操作.? 此時, 就會造成對同一緩沖區(qū)的重復釋放, 問題由此產(chǎn)生.
解決的方法, 可以有這幾種:
1. 對數(shù)據(jù)緩沖區(qū)使用引用計數(shù)機制;
2. 在clientsock的對象設計機制上使釋放操作線性化.
關于這兩種方法, 任何一種如果要詳細說清, 可能篇幅都會比較長, 筆者并無耐心和精力將每一個細節(jié)都一一道來, 在此僅選第2種方案的關鍵步驟和核心思想來與大家分享.
由前面對問題的描述可以看出, 造成多次釋放的原因可能是在執(zhí)行收發(fā)操作和GET函數(shù)返回值為FALSE時, 我們重復執(zhí)行了釋放操作. 很自然地, 我們會想到,? 能不能把這兩次釋放合并成一次釋放,? 這樣不就沒問題了嗎?? yes,? 這個思路是沒問題的.? 但要想讓這個思路能變成現(xiàn)實,? 需要在設計機制上對這個思路進行一定的支持.
首先,? 我們假設, 是在get函數(shù)返回時統(tǒng)一進行相應的釋放和關閉操作.
如果在執(zhí)行wsasend操作時, 發(fā)生了非pending錯誤(io操作正在進行中), 而此時我們如果不釋放資源, 那至少得讓IOCP在GET返回時得知這個錯誤和發(fā)生錯誤時的緩沖區(qū)指針. 通知IOCP的方式, 是使用post函數(shù)(PostQueuedCompletionStatus)向IOCP拋一個特殊標志的消息, 這個特殊標志可以通過get函數(shù)的第二個參數(shù), 即: 傳送字節(jié)數(shù)來表示, 可以選擇任何一個不可能出現(xiàn)的值, 比如任何一個跟它的初始值不相等的負數(shù).? 當然, 如果你通過單句柄數(shù)據(jù)或單IO數(shù)據(jù)來傳遞也是可以的. 而發(fā)生錯誤的這個緩沖區(qū)指針, 我們是必須要通過單句柄數(shù)據(jù)或單IO數(shù)據(jù)來傳遞的. 但是, 從整個緩沖區(qū)的管理機制上來說, 我不推薦這樣的離散緩沖區(qū)機制, 我的建議是: 把收發(fā)緩沖區(qū)或數(shù)據(jù)隊列與相應的clientsocket對象相綁定, 釋放操作寫在該對象的析構函數(shù)里, 這樣當釋放clientsocket對象時就釋放了這些緩沖區(qū).
ok, 這樣一來, 在get函數(shù)里, 有三種情況需要執(zhí)行釋放邏輯:
1. get的返回值為FALSE;
2. 傳送字節(jié)數(shù)為0;
3. 接收到剛才我們post的那個錯誤類型消息.
把釋放操作全放在get函數(shù)里以后, 對釋放操作的處理, 就比較統(tǒng)一了. 當然, 為了實現(xiàn)真正的線性化和元子化, 在釋放操作的最終執(zhí)行邏輯上, 還需要對釋放代碼加鎖以實現(xiàn)線程互斥(當然, 這是在你開了多個工作者線程的情況下).