一套網絡框架的杯具
之前設計了一套網絡框架，持續改進了很多年，使用在很多項目上，綜合效率還行，也很穩定，一直以來對這套東西信心滿滿，總以為啥問題都好解決，但最近就有個需求讓我選擇還是改了下這個框架。
之前的框架是這樣的，可以開一組N個io線程，可以開一組N個同步線程（默認1個），可以開一組N個異步線程（默認1個），可以開一組N個timer線程（默認1個），可以開一組N個異步線程（默認cpu個），每組可獨立受控，每組可支持自定義消息，可支持timer，一組N個如果N大于1則無法直接給這組里面的特定線程發消息，只能給一組發消息，這個組里面會選擇某個合適的線程處理這個消息，這也是iocp高效和典型的用法了，但這也正是問題的結癥所在。
Linux下的多線程服務器更常見的做法跟這個不大相似，一般都是將某些socket分配到某些線程epoll，分好之后就是固定的，不再變化，跟Iocp將socket綁定到一組線程的做法不同，由于某個socket直接綁定到了某個線程，所以有些問題就變得簡單了，如同一個連接的在同一個線程內消息進行了同步，要跟io線程綁定私有化數據也簡單了，而且每個線程可獨立受控，所以很容易實現一組io各自掛tls（線程局部存儲）數據，而我現在做的這套框架就是這方面不好控了，其實也很難說這兩種意義上的框架到底誰更優，如用在web型應用上這種socket被一組io線程管理的模式很方便效率也高，但我現在的需求需要某個socket使用線程相關數據，以避免數據之間的鎖，我用內存換時間，由于在原來的框架上增邏輯難以實現可直接控制io線程的框架的，所以花了一個晚上重新改寫了一套框架，在原來iocpframe的基礎上派生了一組帶2名稱的類，除替換類名之外只修改了幾十行代碼就做好了，總的來說花的時間還是比較少的。修改后io線程一組，但獨立受控，外部可對這組線程中的某一個直接發消息，基本滿足了需求，現在要給每個io線程綁定私有數據并觸發特定消息比之前簡單多了，而且絕對無鎖。