前言
這應該是Nodejs的運行原理的第7篇分享，這篇過后，短時間內不會再分享Nodejs的運行原理，會停更一段時間，PS：不是不更，而是會開挖新的坑，最近有在研究RPG Maker MV，區塊鏈，雲計算，可能會更新一些相關文章，或者相關教學。
回到正題，異步編程的難點在於請求與響應不是按順序發生的。以http server 為例，異步編程賦予了server 高並發的品質，而且他可以以很小的資源代價，不斷地接受和處理請求。但是快速處理請求不表示快速地返回請求=>高並發不等同於快速反饋。
在Nodejs中，libuv則為異步編程的實現提供了可能。libuv為builtin modules 提供了API，這些API用來支撐請求和數據的返回的異步處理方式。
這一篇分享，我們主要討論libuv的運行原理，從兩個角度出發：
1) libuv的架構
2) 案例，從細節的角度看libuv是如何對待不同I/O請求，按照不同的方式來完成異步請求和數據返回的。
Libuv的架構
從左往右可分為兩部分，Network I/O的相關請求，另一部分File I/O，DNS Ops和User Code組成。
上圖展示了libuv細節的流程，圖中代碼很簡單，包括2個部分：
1. server.listen()是用來創建TCP server時，通常放在最后一步執行的代碼。主要指定服務器工作的端口以及回調函數。
2. fs.open()是用異步的方式打開一個文件。
選擇兩個示例很簡單，因為libuv架構圖可視：libuv對 Network I/O和 File I/O采用不同的機制。
上圖右半部分，主要分成兩個部分：
1. 主線程：主線程也是node啟動時執行的現成。node啟動時，會完成一系列的初始化動作，啟動V8 engine，進入下一個循環。
2. 線程池：線程池的數量可以通過環境變量UV_THREADPOOL_SIZE配置，最大不超過128個，默認為4個。
Network I/O
V8 engine執行從server.listen() 開始，調用builtin module Tcp_wrap 的過程。
在創建TCP鏈接的過程中，libuv直接參與Tcp_wrap.cc函數中的 TCPWrap::listen() 調用uv_listen()開始到執行uv_io_start()結束。看起來很短暫的過程，其實是類似linux kernel的中斷處理機制。
uv_io_start()負載將handle插入到處理的water queue中。這樣的好處是請求能夠立即得到處理。中斷處理機制里面的下半部分與數據處理操作相似，交由主線程去完成處理。
代碼邏輯很簡單，查看loop中是否包含handle，如果有遍歷default loop。
File I/O
這里我們研究一下 File I/O。
同Network I/O一樣，我們的應用所依賴的fs模塊，后面有一個builtin module Node_file.cc作為支撐。 Node_file.cc包含了各種我們常用的文件操作的接口，例如open, read, write, chmod,chown等。但同時，它們都支持異步模式。 我們通過Node_file.cc中的Open()函數來研究一下具體的實現細節。
如果你用類似source insight之類的代碼閱讀工具跟蹤一下代碼調用順序，會很容易發現對於異步模式，Open()函數會在一系列輔助操作之后，進入函數uv_fs_open(),並且傳入了一個FSReqWrap的對象。
FSReqWrap()，從名字可以看得出來，這是一個wrap,且是與FS相關的請求。也就是說，它基於某一個現成的機制來實現與FS相關的請求操作。這個現成的機制就是ReqWrap。好吧，它也是個wrap。乘你還沒瘋的時候，看一下圖6吧。這里完整展示了FSReqWrap類繼承關系。
除了FSReqWrap，還有其它Wrap,例如PipeConnectWrap，TCPConnectWrap等等。每個Wrap均為一種請求類型服務。 但是這些wrap，都是node自身的行為，而與libuv相關的是什么呢？上圖中表示出了FSReqWrap關鍵的數據結構 uv_fs_s req__。
讓我們把目光回到uv_fs_open()。在調用這個函數時， req__作為其一個重要的參數被傳遞進去。而在uv_fs_open()內部，req__則被添加到work queue的末尾中去。圖3 thread pool中的thread會去領取這些request進行處理。 每個request很像一個粘貼板，它將event loop, work queue，每個請求的處理函數(work())，以及請求結束處理函數(done())綁定在一起。綁定的操作在uv__work_submit()中完成。 例如對於這里的req__，綁定在它身上的work()為uv__fs_work(), done()為uv__fs_done()。
這里有一個比較有意思的問題值得額外看一下。我們的thread pool是在什么時候建立的呢？
答案是：在第一次異步調用uv__work_submit()時。
每個thead的入口函數是 Threadpool.c中的worker()。工作邏輯比較簡單，依次取出work queue中的請求，執行綁定在該請求上的work()函數。 前面我們提到的綁定在請求上的done()函數在哪里執行呢？這也是一個比較有意思的操作。libuv通過uv_async_send()通知event loop去執行相應的callback函數，也即我們綁定在request上的done()函數。uv__work_done()用於完成這樣的操作。
uv_async_send()與主線程之間通過PIPE通信。
我在這一小節以一個FSReqWrap以及Open()函數為例，描述了libuv處理這種File I/O請求時所涉及的各種操作：
- 建立thread pool(只建立一次)
- 在每個請求req__上綁定與其相關的event loop, work queue, work(), done()
- thread worker()用來處理work queue里面的每個請求，並執行work()
- 通過uv_async_send()通知event loop執行done()