Nginx裡面的事件處理與其他伺服器所做的事件處理模型其實大同小異---都是封裝了一個事件通知的結構體，然後會對每個平臺上常用的事件觸發器做封裝（epoll/select/poll/...），根據編譯時配置來決定選擇哪個事件處理器，當然，這個選擇也可以在配置檔案中指定。

封裝事件處理的結構體在ngx_event_s中定義，其中的handler是處理事件的函式指標。

對於監聽socket而言，這個handler函式指標指向的是函式ngx_event_accept函式。顯然，這個函式是用於接收新連線。
當接收新的連線之後，對連線socket而言，這個函式指標指向ngx_http_init_request 函式。假如這個函式執行成功，handler函式指標會改為指向ngx_http_process_request_line函式。其他的以此類推，我沒有繼續跟進這些與http具體業務相關的處理函式。

所以，可以看到，在處理一個連線請求的每個階段，都對應的是不同的handler函式，在每個handler函式中，會在執行成功之後修改handler函式指標指向下一個階段的處理函式。

與之前分析過的

lighhtpd的狀態機相比，Nginx裡面的handler函式之間，耦合關係更緊密一些，也就是說，在狀態處理的每個階段，都需要知道下一個階段是由哪個函式進行處理。我個人更喜歡lighttpd的狀態機，因為這個狀態機使得每個階段的狀態耦合的不那麼緊密，每次狀態處理完畢，該狀態的處理函式只需要儲存本次處理的結果，然後進入狀態機處理函式中，由它來選擇處理的走向。