近來在Windows下用WSAEventSelect時，碰到一個棘手的問題，當然現在已經解決了。
問題描述：
一個Server，一個ClientA，一個ClientB，Server用WSAEventSelect模型監聽（只有監聽，沒有讀寫），ClientA在連接Server後，ClientA對應的EventA被觸發，Server的WSAWaitForMultipleEvents等待到EventA，ClientB連接Server時，TCP三次握手成功，ClientB與Server的TCP狀態被置爲ESTABLISHED，然而Server的WSAWaitForMultipleEvents沒有等待到EventB被觸發。
用netstat看了一下，ClientB與Server的狀態是ESTABLISHED，此時如果ClientB退出，由於Server無法正常Close該連接，因此Server的狀態不是TIME_WAIT而是CLOSE_WAIT（持續2小時），Client的狀態是FIN_WAIT_2（持續10分鐘）。
我嘗試將ClientA主動關閉後再次連接Server，Server的WSAWaitForMultipleEvents在wait到EventA之後，EventB此時也被觸發。
開始一直以爲問題的根源在於WSAEventSelect的使用上，畢竟，之前沒有系統寫過類似的代碼，難免懷疑到事件模型的使用上。多方查閱資料，最後還是沒有發現類似問題的解決方案。
又跟了一上午之後，Kevin開始懷疑是多線程使用的問題，我看了一下，的確沒有對event的多線程操作進行處理，但因爲在另一個應用中，使用了同樣的模塊，卻沒有該問題。最後考慮必要性時還是放棄了加臨界資源，無視多線程同步問題。Kevin本來勸我換個模型，但我固執的認爲要做就把這事兒做好。因爲下午還要回學校一趟，就想盡快搞定，畢竟因爲這一塊已經把Kevin的進度拖了一週了，心下還是過意不去，而且隱約感覺到離問題的解決越來越近了。
問題分析：
在對着WSAWaitForMultipleEvents思考了半天之後，忽然開竅了，如果ThreadA在WSAWaitForMultipleEvents時，只有一個EventA被WSAEventSelect並set到signaled狀態，則該EventA會被wait成功，ThreadA處理EventA之後繼續阻塞在WSAWaitForMultipleEvents。此時，ThreadB通過WSAEventSelect將EventB初始化爲nonsignaled狀態，之後即使EventB被set爲signaled狀態，但ThreadA的WSAWaitForMultipleEvents因爲處於阻塞狀態，不可能刷新事件集，也就不可能wait到EventB，最終導致了ClientB的請求無法被響應。如果EventA被觸發則會被ThreadA等待到，WSAWaitForMultipleEvents返回後再次進入時事件集已經被刷新，EventB被wait到也就不難理解了。
問題解決：
說到底是因爲當ThreadA阻塞在WSAWaitForMultipleEvents處之時，事件集的變更無法立即得到體現。如果允許上層應用隨時create或close一些event，則WSAWaitForMultipleEvents就不應該無限阻塞下去。
因此最後的一個解決方法就是讓WSAWaitForMultipleEvents超時返回並Sleep一段時間，當WSAWaitForMultipleEvents再次進入時事件集得以更新。
想了一下，另一個應用中之所以沒出現該問題也只是個巧合，因爲該應用中ThreadB的兩次WSAEventSelect間隔很短，在ThreadA獲得時間片之前已經確定了事件集。
說白了這也不是一個什麼大問題，甚至談不上任何難度，但是因爲之前對WSAEventSelect沒有一個清晰的概念，因此在發現和分析問題上花費了大量時間，加上在VS2005調試過程中，有個別文件更新時沒有被重新編譯，也耗費了很多無謂的時間，以至於我們都在考慮是不是要放棄IDE，因爲我們確實太依賴IDE了，有些TX爲了穩妥，每次都是“重新生成整個解決方案”，如果一個解決方案有幾千個文件、幾十萬行的代碼，估計重編一次也要花個幾分鐘吧。
總結：
- netstat觀察的網絡連接處於ESTABLISHED狀態並不意味着邏輯連接被accept，只是表明客戶端connect的TCP物理連接（三次握手）被服務器端ack，如果服務器沒有accept到該連接，證明網絡模塊代碼有問題；
- 多線程怎麼都是個問題，線程同步儘量避免，畢竟，用Kevin的話來說，加鎖是醜陋的。但在涉及到同步問題時，還是權衡一下，我這兒之所以最後沒有加臨界區，是因爲事件主要是在ThreadA中處理，ThreadB中只有create操作，而且ThreadA對事件集的刷新要求不是那麼嚴格，也就不考慮加臨界區了；
- 如果能力和條件允許的話，放棄IDE吧，IDE的確不是個好東西，我主要是指在編譯鏈接的時候，如果作爲編輯器說不定還會好用:)。