淺析libuv源碼-node事件輪詢解析(2)

　　上一篇講了輪詢的邊角料，這篇進入正題。(補兩個圖)

Poll for I/O

The loop blocks for I/O. At this point the loop will block for I/O for the duration calculated in the previous step. All I/O related handles that were monitoring a given file descriptor for a read or write operation get their callbacks called at this point.

　　簡單來說，就兩點：

一、根據計算的timeout來進行I/O操做，這裏的操做包括fs.readFile、fs.stat等，期間進程將被阻塞。

二、全部I/O的handles會使用一個給定的文件描述符進行操做，並會調用對應的callbacks。

Call pengding callbacks

Pending callbacks are called. All I/O callbacks are called right after polling for I/O, for the most part. There are cases, however, in which calling such a callback is deferred for the next loop iteration. If the previous iteration deferred any I/O callback it will be run at this point.

　　從解釋中看不出什麼信息，但只有這一步真正調用咱們從JS傳過去的callback。

　　既然要解析，那麼不如從一個API入手，走一遍看代碼流向。

　　這裏仍是用以前fs.stat方法，雖然在前面( www.cnblogs.com/QH-Jimmy/p/…)有過看似很深刻的解釋，但也只是蜻蜓點水的看了一遍，此次從新梳理一遍。

　　與上篇同樣，省略大量無關源碼。

JavaScript層

　　一樣從簡易的lib/fs.js文件中出發，此次着重注意的是傳過去的三個參數。

function stat(path, options, callback) {
  // ...
  // FSReqCallback是來源於c++層的一個class
  const req = new FSReqCallback(options.bigint);
  req.oncomplete = callback;
  // 這裏的第三個參數是一個Object 回調函數僅做爲一個oncomplete屬性
  binding.stat(pathModule.toNamespacedPath(path), options.bigint, req);
}複製代碼

　　以下:

一、第一個是處理過的路徑path

二、第二個是一個可選參數，通常狀況沒人傳，本文也不會作解析，畢竟不是重點

三、第三個是一個新生成的對象，而不是將咱們的function直接做爲參數傳到stat方法中

node層

　　接下來直接到src/node_file.cc文件中，這裏會檢測參數並作包裝，不用懂C++直接看註釋。

static void Stat(const FunctionCallbackInfo<Value>& args) {
  Environment* env = Environment::GetCurrent(args);
  // 檢測參數數量是否大於2
  const int argc = args.Length();
  CHECK_GE(argc, 2);
  // 檢測path參數合法性
  BufferValue path(env->isolate(), args[0]);
  CHECK_NOT_NULL(*path);
  // 檢測是否傳了use_bigint
  bool use_bigint = args[1]->IsTrue();
  // 在同步調用stat的狀況下 這個class爲空指針
  // if、else後面有同步/異步調用時參數狀況
  FSReqBase* req_wrap_async = GetReqWrap(env, args[2], use_bigint);
  if (req_wrap_async != nullptr) {  // stat(path, use_bigint, req)
    AsyncCall(env, req_wrap_async, args, "stat", UTF8, AfterStat,
              uv_fs_stat, *path);
  } else {  // stat(path, use_bigint, undefined, ctx)
    // 同步狀況...
  }
}複製代碼

　　在以前那一篇講node架構時，這塊只是簡單說了一下，直接跳到同步調用那塊了。

　　可是隻有在異步調用的時候纔會出現poll for I/O，因此此次跳過同步狀況，來看異步調用狀況。(那一篇的異步狀況是瞎雞兒亂說的，根本無法看)

　　首先整理一下AsyncCall方法的參數。

AsyncCall(env, req_wrap_async, args, "stat", UTF8, AfterStat,uv_fs_stat, *path);複製代碼

env => 一個萬能的全局對象，能存東西能作事情。能夠經過env->isolate獲當前取V8引擎實例，env->SetMethod設置JS的對象屬性等等

req_wrap_async => 一個包裝類

args => 從JavaScript層傳過來的函數數組，能夠簡單理解爲arguments

"stat" => 須要調用的fs方法名字符串

UTF8 => 編碼類型

AfterStat => 一個內置的一個回調函數

uv_fs_stat => 異步調用的實際方法

*path => 路徑參數

　　參數看完，能夠進到方法裏，這是一個模版函數，不過也沒啥。

// Func類型爲普通函數
// Args爲路徑path
template <typename Func, typename... Args>
inline FSReqBase* AsyncCall(Environment* env, FSReqBase* req_wrap, const FunctionCallbackInfo<Value>& args, const char* syscall, enum encoding enc, uv_fs_cb after, Func fn, Args... fn_args) {
  return AsyncDestCall(env, req_wrap, args, syscall, nullptr, 0, enc, after, fn, fn_args...);
}

template <typename Func, typename... Args>
inline FSReqBase* AsyncDestCall(Environment* env, FSReqBase* req_wrap, const FunctionCallbackInfo<Value>& args, const char* syscall, const char* dest, size_t len, enum encoding enc, uv_fs_cb after, Func fn, Args... fn_args) {
  // 異步調用這個類不能爲空指針
  CHECK_NOT_NULL(req_wrap);
  // 依次調用包裝類的方法
  req_wrap->Init(syscall, dest, len, enc);
  int err = req_wrap->Dispatch(fn, fn_args..., after);
  if (err < 0) {
    // 出現error的狀況 不用看...
  } else {
    req_wrap->SetReturnValue(args);
  }

  return req_wrap;
}複製代碼

　　看似一大團，實際上函數內容很是少，僅僅只有一個Init、一個Dispatch便完成了整個stat操做。

　　因爲都來源於req_wrap類，因此須要回頭去看一下這個類的內容。

FSReqBase* req_wrap_async = GetReqWrap(env, args[2], use_bigint);
inline FSReqBase* GetReqWrap(Environment* env, Local<Value> value, bool use_bigint = false) {
  if (value->IsObject()) {
    return Unwrap<FSReqBase>(value.As<Object>());
  } else if (value->StrictEquals(env->fs_use_promises_symbol())) {
    // Promise狀況...
  }
  return nullptr;
}複製代碼

　　不用看Promise的狀況，在最開始的講過，傳過來的第三個參數是一個新生成的對象，因此這裏的args[2]正好知足value->IsObject()。

　　這裏的return比較魔性，沒有C++基礎的不太好講，先看看源碼。

// 這個T表明須要被強轉的類 即FsReqBase
template <class T> static inline T* Unwrap(v8::Local<v8::Object> handle) {
  // ...
  // 這裏是類型強轉
  return static_cast<T*>(wrap);
}

class FSReqBase : public ReqWrap<uv_fs_t> {
 public:
  // ...
  void Init(const char* syscall, const char* data, size_t len, enum encoding encoding) {}
}

template <typename T>
class ReqWrap : public AsyncWrap, public ReqWrapBase {
 public:
  // ...
  inline int Dispatch(LibuvFunction fn, Args... args);

 private:
  // ...
};複製代碼

　　剔除了全部無關的代碼，留下了一些關鍵信息。

　　簡單來說，這裏的Unwrap是一個模版方法，做用僅僅是作一個強轉，關鍵在於強轉的FsReqBase類。這個類的繼承鏈比較長，能夠看出類自己有一個Init，而在父類ReqWrap上有Dispatch方法，知道方法怎麼來的，這就足夠了。

　　這裏從新看那兩步調用。

req_wrap->Init(syscall, dest, len, enc);
int err = req_wrap->Dispatch(fn, fn_args..., after);複製代碼

　　首先是Init。

void Init(const char* syscall, const char* data, size_t len, enum encoding encoding) {
  syscall_ = syscall;
  encoding_ = encoding;

  if (data != nullptr) {
    // ...
  }
}複製代碼

　　四個參數實際上分別是字符串"stat"、nullptr、0、枚舉值UFT8，因此這裏的if不會走，只是兩個賦值操做。

　　接下來就是Dispatch。

template <typename T>
template <typename LibuvFunction, typename... Args>
int ReqWrap<T>::Dispatch(LibuvFunction fn, Args... args) {
  Dispatched();

  // This expands as:
  //
  // int err = fn(env()->event_loop(), req(), arg1, arg2, Wrapper, arg3, ...)
  // ^ ^ ^
  // | | |
  // \-- Omitted if `fn` has no | |
  // first `uv_loop_t*` argument | |
  // | |
  // A function callback whose first argument | |
  // matches the libuv request type is replaced ---/ |
  // by the `Wrapper` method defined above |
  // |
  // Other (non-function) arguments are passed -----/
  // through verbatim
  int err = CallLibuvFunction<T, LibuvFunction>::Call(fn, env()->event_loop(), req(), MakeLibuvRequestCallback<T, Args>::For(this, args)...);
  if (err >= 0)
    env()->IncreaseWaitingRequestCounter();
  return err;
}複製代碼

　　這個方法的內容展開以後巨麻煩，懶得講了，直接看官方給的註釋。

　　簡單來講，就是至關於直接調用給的uv_fs_stat，參數依次爲事件輪詢的全局對象loop、fs專用handle、路徑path、包裝的callback函數。

　　這篇先這樣。