斷點的實現(xiàn)非常復(fù)雜，這里并不是說要長篇大論講解 JS 斷點在 V8 中是如何實現(xiàn)的，而是想從宏觀上聊一下斷點的實現(xiàn)。這個問題來源于最近和同事討論的關(guān)于 V8 Inspector 實現(xiàn)的一些事情。

JS 斷點的功能相信大家都用過，當我們設(shè)置一個斷點，然后代碼執(zhí)行到這個斷點時，線程就會停住，然后我們點擊下一步的時候，又會再下一個斷點停住。那么這個停住到底意味著什么呢？下面這個圖是執(zhí)行到一個斷點時 Node.js 的調(diào)用棧。

我們知道 V8 有一個調(diào)試協(xié)議，客戶端是和 V8 通過這個協(xié)議通信完成調(diào)試的，當 V8 收到客戶端的信息并且處理完之后，就會調(diào)用 runMessageLoopOnPause。runMessageLoopOnPause 是 V8 提供的一個約定的 API，當執(zhí)行到 JS 斷點時就會調(diào)用，具體在 runMessageLoopOnPause 里做什么事情由 V8 的使用方實現(xiàn)。在看實現(xiàn)之前，先來思考一下，應(yīng)該怎么處理。首先執(zhí)行到了 JS 斷點，顯然線程就要進入停住的狀態(tài)，那么這個停住的狀態(tài)具體是指什么，應(yīng)該怎么實現(xiàn)是一個最關(guān)鍵的問題。這個事件循環(huán)的實現(xiàn)有點類似，那就是當線程沒有任務(wù)處理的時候，它應(yīng)該在做什么，輪詢顯然太不可思議了，那另一種就是基于訂閱 / 發(fā)布機制實現(xiàn)睡眠 / 喚醒，比如 Node.js 基于事件驅(qū)動模塊實現(xiàn)了睡眠 / 喚醒機制。類似的 Inspector 也是這樣實現(xiàn)，但是具體細節(jié)不一樣，因為如果情況不一樣，當 Node.js 處于事件循環(huán)的阻塞狀態(tài)時，任何注冊到事件驅(qū)動模塊的事件都可以喚醒 Node.js，但是斷點不一樣，當線程處于斷點時，除了信號外，一般的任務(wù)，比如文件 IO、網(wǎng)絡(luò) IO 等，是不能也不應(yīng)該能喚醒線程的，所以這里使用的是簡單的睡眠 / 喚醒方式，那就是條件變量。當線程阻塞于條件變量時，只有通過該條件變量才能喚醒線程。回到斷點的場景，那就是客戶端繼續(xù)執(zhí)行時才能喚醒線程。

分析完之后，來看看 Node.js 的實現(xiàn)。

void runMessageLoopOnPause(int context_group_id) override {
  waiting_for_resume_ = true;
  runMessageLoop();
}

void runMessageLoop() {
  if (running_nested_loop_)
    return;

  running_nested_loop_ = true;

  while (shouldRunMessageLoop()) {
    if (interface_) interface_->WaitForFrontendEvent();
    env_->RunAndClearInterrupts();
  }
  running_nested_loop_ = false;
}

重點在 WaitForFrontendEvent。

bool MainThreadInterface::WaitForFrontendEvent() {
  dispatching_messages_ = false;
  // 任務(wù)隊列為空則阻塞
  if (dispatching_message_queue_.empty()) {
    Mutex::ScopedLock scoped_lock(requests_lock_);
    while (requests_.empty()) incoming_message_cond_.Wait(scoped_lock);
  }
  return true;
}

我們假設(shè)這時候隊列為空，那么線程就會阻塞在條件變量 incoming_message_cond_ 中。接下來看看如聊聊第二個問題。線程這時候阻塞了，那么客戶端點擊執(zhí)行下一步的時候，Node.js 還還怎么處理？這里就需要子線程幫忙了，所以 Node.js 中，和客戶端的數(shù)據(jù)通信是在子線程完成的，不講太多代碼和細節(jié)，直接看一個調(diào)用棧。

這是客戶端和 Node.js 子線程建立 websocket 連接成功后的調(diào)用棧，后續(xù)的數(shù)據(jù)通信也是類似。來看一下 Post。

void MainThreadInterface::Post(std::unique_ptr<Request> request) {
  Mutex::ScopedLock scoped_lock(requests_lock_);
  bool needs_notify = requests_.empty();
  requests_.push_back(std::move(request));
  if (needs_notify) {
    std::weak_ptr<MainThreadInterface> weak_self {shared_from_this()};
    agent_->env()->RequestInterrupt([weak_self](Environment*) {
      if (auto iface = weak_self.lock()) iface->DispatchMessages();
    });
  }
  incoming_message_cond_.Broadcast(scoped_lock);
}

這里看到了剛才熟悉的數(shù)據(jù)結(jié)構(gòu)，Post 就是往主線程中插入一個任務(wù)，然后喚醒主線程。接著回到 runMessageLoop。

while (shouldRunMessageLoop()) {
  if (interface_) interface_->WaitForFrontendEvent();
  env_->RunAndClearInterrupts();
}

WaitForFrontendEvent 執(zhí)行完畢后，接著執(zhí)行 RunAndClearInterrupts，RunAndClearInterrupts 正是處理 RequestInterrupt 插入的任務(wù)的。剛才插入任務(wù)時我們看到插入了兩個任務(wù) agent_->env()->RequestInterrupt 和 requests_.push_back(std::move(request)) ，RequestInterrupt 插入的任務(wù)中會調(diào)用 DispatchMessages，而 DispatchMessages 就是處理 requests_ 中的任務(wù)的。

void MainThreadInterface::DispatchMessages() {
  dispatching_messages_ = true;
  bool had_messages = false;
  do {
    if (dispatching_message_queue_.empty()) {
      Mutex::ScopedLock scoped_lock(requests_lock_);
      requests_.swap(dispatching_message_queue_);
    }
    had_messages = !dispatching_message_queue_.empty();
    while (!dispatching_message_queue_.empty()) {
      MessageQueue::value_type task;
      std::swap(dispatching_message_queue_.front(), task);
      dispatching_message_queue_.pop_front();

      v8::SealHandleScope seal_handle_scope(agent_->env()->isolate());
      task->Call(this);
    }
  } while (had_messages);
  dispatching_messages_ = false;
}

執(zhí)行任務(wù)的時候，具體做的事情就是把客戶端傳過來的數(shù)據(jù)投傳給 V8 Inspector，如果又執(zhí)行到了一個斷點，那么繼續(xù)本文分析到這個邏輯，否則線程就可以繼續(xù)跑了。