聊聊 JS 斷點的實現
斷點的實現非常復雜，這里并不是說要長篇大論講解 JS 斷點在 V8 中是如何實現的，而是想從宏觀上聊一下斷點的實現。這個問題來源于最近和同事討論的關于 V8 Inspector 實現的一些事情。
JS 斷點的功能相信大家都用過，當我們設置一個斷點，然后代碼執(zhí)行到這個斷點時，線程就會停住，然后我們點擊下一步的時候，又會再下一個斷點停住。那么這個停住到底意味著什么呢？下面這個圖是執(zhí)行到一個斷點時 Node.js 的調用棧。
我們知道 V8 有一個調試協(xié)議，客戶端是和 V8 通過這個協(xié)議通信完成調試的，當 V8 收到客戶端的信息并且處理完之后，就會調用 runMessageLoopOnPause。runMessageLoopOnPause 是 V8 提供的一個約定的 API，當執(zhí)行到 JS 斷點時就會調用，具體在 runMessageLoopOnPause 里做什么事情由 V8 的使用方實現。在看實現之前，先來思考一下，應該怎么處理。首先執(zhí)行到了 JS 斷點，顯然線程就要進入停住的狀態(tài)，那么這個停住的狀態(tài)具體是指什么，應該怎么實現是一個最關鍵的問題。這個事件循環(huán)的實現有點類似，那就是當線程沒有任務處理的時候，它應該在做什么，輪詢顯然太不可思議了，那另一種就是基于訂閱 / 發(fā)布機制實現睡眠 / 喚醒，比如 Node.js 基于事件驅動模塊實現了睡眠 / 喚醒機制。類似的 Inspector 也是這樣實現，但是具體細節(jié)不一樣，因為如果情況不一樣，當 Node.js 處于事件循環(huán)的阻塞狀態(tài)時，任何注冊到事件驅動模塊的事件都可以喚醒 Node.js，但是斷點不一樣，當線程處于斷點時，除了信號外，一般的任務，比如文件 IO、網絡 IO 等，是不能也不應該能喚醒線程的，所以這里使用的是簡單的睡眠 / 喚醒方式，那就是條件變量。當線程阻塞于條件變量時，只有通過該條件變量才能喚醒線程?；氐綌帱c的場景，那就是客戶端繼續(xù)執(zhí)行時才能喚醒線程。
分析完之后，來看看 Node.js 的實現。
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;
// 任務隊列為空則阻塞
if (dispatching_message_queue_.empty()) {
Mutex::ScopedLock scoped_lock(requests_lock_);
while (requests_.empty()) incoming_message_cond_.Wait(scoped_lock);
}
return true;
}
我們假設這時候隊列為空，那么線程就會阻塞在條件變量 incoming_message_cond_ 中。接下來看看如聊聊第二個問題。線程這時候阻塞了，那么客戶端點擊執(zhí)行下一步的時候，Node.js 還還怎么處理？這里就需要子線程幫忙了，所以 Node.js 中，和客戶端的數據通信是在子線程完成的，不講太多代碼和細節(jié)，直接看一個調用棧。
這是客戶端和 Node.js 子線程建立 websocket 連接成功后的調用棧，后續(xù)的數據通信也是類似。來看一下 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);
}
這里看到了剛才熟悉的數據結構，Post 就是往主線程中插入一個任務，然后喚醒主線程。接著回到 runMessageLoop。
while (shouldRunMessageLoop()) {
if (interface_) interface_->WaitForFrontendEvent();
env_->RunAndClearInterrupts();
}
WaitForFrontendEvent 執(zhí)行完畢后，接著執(zhí)行 RunAndClearInterrupts，RunAndClearInterrupts 正是處理 RequestInterrupt 插入的任務的。剛才插入任務時我們看到插入了兩個任務 agent_->env()->RequestInterrupt 和 requests_.push_back(std::move(request)) ，RequestInterrupt 插入的任務中會調用 DispatchMessages，而 DispatchMessages 就是處理 requests_ 中的任務的。
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í)行任務的時候，具體做的事情就是把客戶端傳過來的數據投傳給 V8 Inspector，如果又執(zhí)行到了一個斷點，那么繼續(xù)本文分析到這個邏輯，否則線程就可以繼續(xù)跑了。
