node源码详解(二 )—— 运行机制 、整体流程【markdown版本】
发布于 9 天前 作者 bigtree9307 418 次浏览 最后一次编辑是 1 天前 来自 分享

声明:转载请保留声明头部并标明转载、并私信告知作者。原文:http://www.cnblogs.com/papertree/p/5225201.html

2.1 项目代码结构

node 主要的部分有4个【下图最左列就是node项目源码的根目录】:

  1. 原生 js模块:node提供给 用户js 代码的类接口,平时用的require(‘fs’)、require(‘http’)调用的都是这部分的代码。【最左列的 lib文件夹,展开后是左二列】

  2. node 源码:node程序的main函数入口;还有提供给lib模块的C++类接口。【最左列的 src 文件夹,展开后是第三列】

  3. v8引擎:node用来解析、执行js代码的运行环境。【最左列的deps文件夹展开后是第四列,v8和libuv等依赖都放在这里】

  4. libuv:事件循环库,提供最底层的 io操作接口(包括网络io操作的epoll_wait()、文件异步io的线程池管理)、事件循环逻辑。 【第四列的uv文件夹,展开后是第五列】

记住这几个路径:

./lib

./src

./deps/uv

2-1-1.png

图2-1-1

2.2 运行流程

下图4个红色序号分别对应着上篇博客提出的4个问题所在位置。后续博客分说。

接下来对一些关键地方进行说明:

1. 核心数据结构 default_loop_struct (结构体为struct uv_loop_s,后续祥讲)

这个数据结构是事件循环的核心。当node执行到“加载js文件”这个步骤(结合下图)时,用户的js代码如果有io操作:

那么js代码通过调用 -》lib模块(2.1 中的原生js模块)-》C++模块(2.1中的源码部分) -》 libuv接口(2.1中deps/uv部分) -》最终的系统api,拿到系统返回的一个fd(文件描述符),和 js代码传进来的回调函数callback,封装成一个io观察者(一个uv__io_s类型的对象),保存到default_loop_struct;

2. 进入事件循环

当处理完 js代码,如果有io操作,那么这时default_loop_struct是保存着对应的io观察者的。

处理完js代码,main函数继续往下调用libuv的事件循环入口uv_run(),node进程进入事件循环:

uv_run()的while循环做的就是一件事,判断default_loop_struct是否有存活的io观察者。

a. 如果没有io观察者,那么uv_run()退出,node进程退出。

b. 而如果有io观察者,那么uv_run()进入epoll_wait(),线程挂起等待,监听对应的io观察者是否有数据到来。有数据到来调用io观察者里保存着的callback(js代码),没有数据到来时一直在epoll_wait()进行等待。

这里解答了博客(一)的“问题2”的一部分:为什么console.log()的js代码导致node退出,而server.listen(80)导致线程挂起等待。

3. 这里一旦没搞清逻辑就有个疑问:

第2点说在uv_run()里面如果监听的io观察者有数据到来,那么调用对应的callback,执行js代码。如果没有数据到来,一直在epoll_wait()等待。那如果我js代码里面有新的 io操作想要交给epoll_wait()进行监听,而此刻监听着的io观察者又没有数据到来,线程一直在这里等待,那怎么办?

首先第1点讲到,执行js代码的时候,通过调用node提供的C++接口最终把io观察者都保存到default_loop_struct里面,js代码执行完之后,node继续运行才进入epoll_wait()等待。也就是说node在epoll_wait()的时候,js代码执行完毕了。而js代码的回调函数部分,本来的设定就是在epoll_wait()监听的io观察者被触发之后才会执行回调,在epoll_wait()进行等待的时候,不可能存在“有新io操作要交给epoll_wait()去监听”这样的js代码。

2-2-1.png

图2-2-1
4 回复

@bigtree9307 特别赞那么将自己的见解分享的人 这也是我喜欢node社区的一个原因,现在在读nodeclub码源,过段时间把你的node源码分享来仔细的看一下

编辑了markdown版本方便这边看~

回到顶部