oldworm

你對iocp的理解太膚淺了，iocp最精華的莫過于對多線程的綁定能力，而epoll是沒有這個的，如libevent之類的庫居然按照epoll的模式，弄個所謂的socket消息轉發技巧來實現線程間通知，這在iocp看來就是畫蛇添足。

X說得還挺謙虛的，哈哈。

@by
iocp編程理論上比epoll困難，因為：
1、winsock系列函數眾多，常用的也有幾十個函數，而且參數眾多，而*nix只有區區幾個函數。
2、epoll函數通知之后是非阻塞同步調用，而iocp是異步調用，更難理解，編程也更復雜。
3、iocp模式的框架幾乎沒有單線程模式的，而epoll的框架很多都是單線程的，這和iocp的多線程框架相比難度降低了很多。當然這個不絕對，要視不同實現而定。
iocp異步多線程模式的確是加大了資源管理的難度，我看過很多網絡框架的實現，幾乎都在這上面花了很多精力，但處理得好的極少，即使是無錯的都不多。所以也沒見過幾個寫得好的框架，同樣采用iocp的不同實現，效率相差可能超過百倍，這可能比epoll的不同框架差距更大。
最近的frame2中IO線程分組調度是為了給每個io線程綁定特殊tls數據，并使得這些線程可直接接收指定消息更新tls數據，標準框架還是經典模式的，使用好多年了，高效穩定可靠。

@欲三更
基本不認同你的看法
1、c++解決回調問題還是很靈活的，以上方法都可用，還有更多的方法可用。
2、模塊接口化或com化就可解決模塊間復用問題，這已經是使用很廣泛并且很容易使用的技術。
3、c++做多線程既高效又靈活，你看看有幾個多線程程序不是用c/c++做的？apache nginx chrome ie qq explorer ...
signal我很少用，因為不夠靈活且不是線程安全的，用起來不爽。
跨模塊跨線程都不算是什么大問題，只要管好數據同步和控制同步即可，跟用什么方法回調沒太大關系。

算不上什么大牛啊，有空就寫一點，主要為了和大家交流，向朋友們學習。

@zuhd
很有道理，我也傾向于和你一樣的做法，用更復雜的東西效率低了可控度還下降了，出了問題還難查，再看看并發上如何提高下即可。

@楊粼波
memcached和內存數據庫完全不同，俺要的是數據運算，而不僅僅是存儲key-value

@ouyang
gate升級還是會斷線啊，后端服務器升級用戶不斷線，因為gate維護和客戶端的連接，gate做了job的管理，在后端服務器升級好之后又重新分派job，這樣給用戶的感覺就是執行稍慢了一點。

@true
謝謝批評，虛心接受。

別的不說，就這尺寸也算不上“完美”吧