寫在前面的話
大概一年多以前,我看了一些ligty的程式碼,並且在這裡給出了一些自己的分析,這部分應該到了狀態機部分,後來由於我沒有繼續跟進ligty的程式碼,或者說,不再像最初那樣對它感興趣,所以也就沒有再跟進了.
最近,我開始看一些nginx的程式碼,和當初閱讀ligty一樣,我不知道我會看到哪兒,分析的有多麼深,所以,作為讀者的您,還是把這一系列文章看作是個人的一些學習筆記好了,我隨時看到一些我覺得可以分享的點,隨時在這裡更新一下,但是,我不能保證更新的頻率和數量了.

順便說一句,Nginx的更新似乎非常的頻繁,隔個幾天就有個新的版本,不知道為什麼,這在我之前跟進過的開原始碼中屬於比較少見的了,而這裡的分析,是基於0.7.61版本的程式碼.

============== 分割線 ==============
首先分析的是nginx中的程序管理部分.
之前分析過ligty的monitor+worker模型,簡單的說就是主程序負責建立子程序,然後主程序就阻塞在wait函式上,一旦有子程序退出,這個函式會返回,然後再次創建出新的worker程序來.

Nginx中的程序管理與這個類似.同樣是worker子程序負責真正的幹活.但是,Nginx中,master程序(其實就是ligty中的monitor程序,也就是程式最開始啟動時的程序,也就是所有worker程序的父程序)對子程序的控制更多,不僅僅關注子程序是否退出了,簡單的總結如下:

1) 程序之間通過socketpair來進行通訊,因此,每次建立了一個新的子程序之後,需要同時創建出對應的socketpair,還要把自己的socketpair告訴已經建立好的兄弟子程序.

2) master程序的主迴圈中主要完成以下幾個工作:比如子程序退出,比如使用者發出指令要求重新載入配置檔案,比如使用者發出指令說更新了新的二進位制檔案,等等,所有這些工作,其實都是以訊號的形式來區分,發出不同的訊號意味著不同的動作.Nginx中所謂的“熱更新配置檔案”，“熱更新程式”等都是通過這個來實現的。

3) worker程序的主迴圈除了一般的監聽網路I/O事件如客戶端連線上來,可讀/寫之外,還需要將自己的socketpair加入到監聽socket中,因為master程序就是通過向這些子程序的socketpair傳送訊號來通知子程序完成不同的操作.

以上,就是Nginx中程序管理的大致模型了,其實看明白了,也不復雜.
我不打算羅列程式碼了,在

這裡,有一份更加詳細的涉及程式碼的分析.

可以看到,Nginx和ligty一樣,都沒有采用非常複雜的程序模型,都是多程序 + 非阻塞I/O + 多路複用I/O處理的網路模型,這在我之前提到半同步半非同步模式時也提到過.