結論
以前總覺得muduo寫的不錯，以後用這個就可以了，但是現在看來，muduo還是有點單薄。
原因原因是什麼呢，是上次開會，老闆說了一種場景。客戶端c1向服務端s1發起登入請求，但是s1要先向s2請求c1是否在黑名單，s2返回資料之後s1才能響應c1的請求。
阻塞肯定是可以完成的，現在考慮的是非阻塞的情況。那麼非阻塞的話，s1就不能用epoll主線程來完成這項操作。那麼辦法就只有通過task扔給執行緒池，但是muduo的執行緒池是沒辦法傳遞資料進去的，也沒辦法告訴執行緒池完成對應工作之後要調哪個特定的函式。這樣就導致s1的執行緒給s2發完請求之後就會結束，重歸到執行緒池中。而s2回來的請求由於沒有上下文，導致s1無法處理。即使s1的執行緒阻塞在那裡等待s2的會話，那也會導致s2回訊息之後s1的執行緒接了這個資料之後要繼續做什麼操作，也就是說s1的執行緒不知道c1在等待他的資料。
我覺著muduo是不能處理這種業務邏輯比較複雜的操作的，從他定義的task void()就可以看出來，中間沒辦法傳遞資料進去，結果也不好傳出來。
所以說muduo是乙個很好的網路庫，但僅僅只是乙個網路庫而已。
業務邏輯還需要在上面再進行封裝。
解決方案：
嗯，可以在上面加乙個entity，用multiplexer來管理的那種。
具體來說就是entity定義s1接收c1訊息之後傳遞給s2進行驗證並且將驗證結果交還給c1的過程。
multiplexer用來將s2傳回給s1的資料交付給對應的entity。
對Python shell的一些思考
對python shell的一些思考 就兩次指令碼處理的編碼練習而言，我感覺如果使用python去寫指令碼來處理日常事務的話，相對於shell是一件比較麻煩的事情，因為我可以使用shell在花費更少的時間內，比較熟練地使用awk sed和grep這些常用的命令在非常簡短的指令碼語句內，完成pytho...
對迷茫的一些思考
最近依然迷茫不安，從3月份開始嘗試去找工作，現在已經4月底，依然沒有著落。不是沒有好機會，而是自己能力不足，抓不住機會，於是自己很慌亂，發現不會或不擅長的東西，拼命在補，同時也在後悔為什麼當初沒有好好努力。然後也明白了一些道理。人們總說學習永遠不晚，其實是會晚的，會錯過很多時機，但時機是不會再次到來...
對程式設計的一些思考
1.程式 是程式設計思想的體現 我想程式設計人員在設計程式之初，肯定會有一番思考。思考主要是程式設計的目的，然後是實現目的的方法，最後才是 的實現。所以，程式 是程式設計思想的體現。分析 的啟示 我們分析程式 時，可以在看 之前，想想這個 要幹什麼事，然後再去看 就容易多了。程式設計的啟示 先思考程...