事件庫之Libev(五)

##其餘監控器 最主要的幾個監控器搞定了。其餘的我以爲比較能夠看的還有ev_child和ev_stat。其實和以前的三個基本原理的是同樣。暫不贅述。將來可能補充。

##Libev中的Tips 若是將Libev當成組件去用的話。官方文檔是一份很好的選擇。這裏說下看Libev過程當中的感覺。

若是使用Libev但又以爲它沒有提供必要的功能而要去該其代碼。可能Libuv爲咱們作了一個很好的示例。Libuv以前是用Libev做爲其底層事件庫。後來做者重寫了本身的一套網絡庫Libuv。嚴格意義上說，Libev僅僅是一個事件模型框架，並不能算上是一個完整的網絡庫，正由於如此他才提供瞭如此多的事件類型。而對於網絡庫可能最重要的就是定時器、IO、以及信號事件。固然網絡還包括了socket、收發控制等內容。所以，個人感受是能夠將Libev當成一個很好的學習對象，不管是其設計思想、仍是代碼中個各類小tips、還有其對跨平臺支持的方法都是很好的示例。雖然用宏包裹的比較嚴密，只要稍加分析，理清其思路仍是比較容易的。

將Libev和以前的Redis-ae進行對比。能夠發現Libev在設計思想上更完整，提供的服務也更全，可是作的檢測多了，邏輯複雜了，消耗的資源也一定比簡單的封裝更多。從這個兩個模型能夠看出事件模型的框架都是：

取得一個合適的時間，用這個時間去poll。而後標記poll以後pending的文件對象。poll出來後判判定時器而後統一處理pending對象

這裏繪製一個總體的結構圖，不是很規範UML或者其餘什麼學術的圖，只是一個幫助理解的過程：

至此Libev的分析差很少完成了，主要去了解實現的思路。具體如何實現以及從什麼樣的角度去設計。其結果須要在生產環境中去檢驗。