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

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

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

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

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

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

@楊粼波
memcached和內(nèi)存數(shù)據(jù)庫完全不同，俺要的是數(shù)據(jù)運算，而不僅僅是存儲key-value

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

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

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