全球消息!聊聊 JS 断点的实现
2022-09-30 08:48:30来源:编程杂技
(资料图片仅供参考)
断点的实现非常复杂,这里并不是说要长篇大论讲解 JS 断点在 V8 中是如何实现的,而是想从宏观上聊一下断点的实现。这个问题来源于最近和同事讨论的关于 V8 Inspector 实现的一些事情。
JS 断点的功能相信大家都用过,当我们设置一个断点,然后代码执行到这个断点时,线程就会停住,然后我们点击下一步的时候,又会再下一个断点停住。那么这个停住到底意味着什么呢?下面这个图是执行到一个断点时 Node.js 的调用栈。
我们知道 V8 有一个调试协议,客户端是和 V8 通过这个协议通信完成调试的,当 V8 收到客户端的信息并且处理完之后,就会调用 runMessageLoopOnPause。runMessageLoopOnPause 是 V8 提供的一个约定的 API,当执行到 JS 断点时就会调用,具体在 runMessageLoopOnPause 里做什么事情由 V8 的使用方实现。在看实现之前,先来思考一下,应该怎么处理。首先执行到了 JS 断点,显然线程就要进入停住的状态,那么这个停住的状态具体是指什么,应该怎么实现是一个最关键的问题。这个事件循环的实现有点类似,那就是当线程没有任务处理的时候,它应该在做什么,轮询显然太不可思议了,那另一种就是基于订阅 / 发布机制实现睡眠 / 唤醒,比如 Node.js 基于事件驱动模块实现了睡眠 / 唤醒机制。类似的 Inspector 也是这样实现,但是具体细节不一样,因为如果情况不一样,当 Node.js 处于事件循环的阻塞状态时,任何注册到事件驱动模块的事件都可以唤醒 Node.js,但是断点不一样,当线程处于断点时,除了信号外,一般的任务,比如文件 IO、网络 IO 等,是不能也不应该能唤醒线程的,所以这里使用的是简单的睡眠 / 唤醒方式,那就是条件变量。当线程阻塞于条件变量时,只有通过该条件变量才能唤醒线程。回到断点的场景,那就是客户端继续执行时才能唤醒线程。
分析完之后,来看看 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_ 中。接下来看看如聊聊第二个问题。线程这时候阻塞了,那么客户端点击执行下一步的时候,Node.js 还还怎么处理?这里就需要子线程帮忙了,所以 Node.js 中,和客户端的数据通信是在子线程完成的,不讲太多代码和细节,直接看一个调用栈。
这是客户端和 Node.js 子线程建立 websocket 连接成功后的调用栈,后续的数据通信也是类似。来看一下 Post。
void MainThreadInterface::Post(std::unique_ptrrequest) { Mutex::ScopedLock scoped_lock(requests_lock_); bool needs_notify = requests_.empty(); requests_.push_back(std::move(request)); if (needs_notify) { std::weak_ptr 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 执行完毕后,接着执行 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;}
执行任务的时候,具体做的事情就是把客户端传过来的数据投传给 V8 Inspector,如果又执行到了一个断点,那么继续本文分析到这个逻辑,否则线程就可以继续跑了。