随笔- 14  评论- 23  文章- 0 

node源码详解(二 )—— 运行机制 、整体流程

知识共享许可协议本作品采用知识共享署名 4.0 国际许可协议进行许可。转载保留声明头部与原文链接https://luzeshu.com/blog/nodesource2 
本博客同步在https://cnodejs.org/topic/56e3be21f5d830306e2f0fd3 
本博客同步在http://www.cnblogs.com/papertree/p/5225201.html 


 2.1 项目代码结构

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

 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

 


 

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

posted on 2016-03-12 14:01 野路子程序员 阅读(...) 评论(...) 编辑 收藏