// 说明
Node API 版本为 v0.10.31。
中文参考:http://nodeapi.ucdok.com/#/api/,http://blog.sina.com.cn/oleoneoy
本段为博主注解。
目录
● 进程
○ Event: 'exit'
○ Event: 'uncaughtException'
○ Signal Events
○ process.stdout
○ process.stderr
○ process.stdin
○ process.argv
○ process.execPath
○ process.execArgv
○ process.abort()
○ process.chdir(directory)
○ process.cwd()
○ process.env
○ process.exit([code])
○ process.getgid()
○ process.setgid(id)
○ process.getuid()
○ process.setuid(id)
○ process.getgroups()
○ process.setgroups(groups)
○ process.initgroups(user, extra_group)
○ process.version
○ process.versions
○ process.config
○ process.kill(pid, [signal])
○ process.pid
○ process.title
○ process.arch
○ process.platform
○ process.memoryUsage()
○ process.nextTick(callback)
○ process.maxTickDepth
○ process.umask([mask])
○ process.uptime()
○ process.hrtime()
进程
process 对象是一个全局对象,能在任何地方被访问。它是一个 EventEmitter 实例。
当进程将要退出时发射。在这个时候没有任何途径来阻止退出事件循环,且当所有的 exit 监听器运行完之后进程将会退出。因此,在本监听器内你必须只使用同步的操作。这是一个很好的执行模块状态的检验的钩子(比如用于单元测试上)。回调函数有一个参数,即进程的退出码。
监听 exit 的例子:


当一个异常一路冒泡到事件循环时发射。如果为这个异常添加了一个监听器,那么默认的动作(打印堆栈信息并退出)将不会被触发。
监听 uncaughtException 的例子:


注意 uncaughtException 是一种非常粗鲁的异常捕获途径且有可能在将来移除。
不要使用它,使用 domains 取代。如果你使用了它,在每个没被正常捕获的异常后重启你的应用程序。
不要使用它因为 node.js 相当于出了错待会恢复重新开始。一个未捕获的异常意味着你的应用程序——推而广之 node.js 本身处于未知状态。盲目地恢复意味着什么事情都有可发生。
假想当你正在升级系统时拔了电源线,然后恢复了。十次有九次都没事发生——但在第十次,你的系统就崩了。
你已经被警告过。
当进程受到一个信号时发射。参看 sigaction(2) 列出的标注 POSIX 信号,例如 SIGINT,SIGHUP等。
监听 SIGINT 的例子:
在大多数的终端程序中一个简单的发送 SIGINT 信号的方法是使用 Control-C。
注意:
SIGUSR1 被 node.js 保留用以启动 debugger。可以创建一个监听器但那不会停止 debugger 的启动。
SIGTERM 和 SIGINT 在非 Windows 平台下有默认的监听器,退出并在退出前重置终端 mode 为128加信号数值。如果这两信号之一创建了监听器,它们的默认操作将会被移除(node 将永不退出)。
SIGPIPE 默认被忽略,他可以创建监听器。
SIGHUP 在 Windows 下当控制台窗口被关闭时产生,在其他平台各个类似的条件下,参看 signal(7)。它可以创建监听器,然而 node 将在大约10秒后被 Windows 无条件终止。在非 Windows 平台下,SIGHUP 的默认行为是终止 node,但一旦创建了监听器默认的行为将被移除。
SIGTERM 在 Windows 下不支持,可以被监听。
SIGINT 从终端发送该信号能被所有平台支持,且通常可以用 CTRL+C 产生(即使这是可配置的)。当终端 raw 模式启动时它不能被产生。
SIGBREAK 在 Windows 下当按下 CTRL+BREAK 时产生,在非 Windows 平台下可以别监听,但没有途径可以发送或产生它。
SIGWINCH 当控制台改变大小时产生。在 Windows 下,这只会发生在鼠标正在移动时向控制台输入,或刻度的 tty 在 raw 模式下使用。
SIGKILL 不可被监听,在任何平台下 node 都将无条件终止。
SIGSTOP 不可被监听。
注意 Windows 不支持发送信号,但 node 使用 process.kill() 和 child_process.kill() 提供了一些模拟:——发送信号0可以用来查找进程是否存在——发送SIGINT,SIGTERM 和 SIGKILL 让目标进程无条件退出。
写向标准输出的可写流。
例子:console.log 的定义
process.stderr 和 process.stdout 和 Node 中的其他流不同,向它们写入通常是阻塞的。
当它们指向普通文件或 TTY 文件描述符时它们是阻塞的。
当它们指向管道:
○ 在 Linux/Unix 下是阻塞的。
○ 在 Windows 下与其他流一样是非阻塞的。
要检验 Node 是否运行在 TTY 上下文中,参看 process.stderr,process.stdout 或 process.stdin 的 isTTY 属性:


更多信息参看 tty 文档。
写向标准错误输出的可写流。
process.stderr 和 process.stdout 和 Node 中的其他流不同,向它们写入通常是阻塞的。
标准输入的可写流。
打开标准输入并监听两个事件的例子:


作为一个流,process.stdin 也可以用于“老”模式,那是为了兼容使用 v0.10 之前的 node 所写的代码。更多信息参看流兼容性。
在“老”模式下标准输入流默认是暂停的,所以必须调用 process.stdin.resume() 来从从里面读取。而且需要注意调用 process.stdin.resume() 本身会将流选择为“老”模式。
如果你正在启动一个新项目,你应该选择更现代的“新”流模式而不是“老”的。
一个包含命令行参数的数组。第一个元素为 'node',第二个元素为 JavaScript 文件名。剩下的参数为附加的命令行参数。
输出将会是:
这是启动进程的可执行程序的绝对路径。
例子:
这是启动进程的可执行程序的 node 特殊的命令行参数集。这些选项不会在 process.argv 出现,且不会包括 node 可执行程序,脚本名,或任何在脚本名后的选项。当为了使用父进程同样的执行环境创建子进程,这些参数是有用的。
例子:
process.execArgv 的结果:
process.argv 的结果:
这会导致 node 发射一个 abort。这回引起 node 退出并创建一个核心文件。
改变进程的当前工作目录或如果失败则抛出一个异常。


返回进程的当前工作目录。
一个包含用户环境的对象。参看 environ(7)。
使用指定的 code 停止进程。如果省略,使用“成功”码 0 退出。
使用一个“失败”码退出:
执行 node 的 shell 将看到1作为退出码。
注意:这个函数只在 POSIX 平台下可用(也就是 Windows 不能使用)
获取进程的组标识。(参看 getgid(2)。)这是数字组 id,不是组名。
设置进程的组标识。(参看 setgid(2)。)接收一个数值 ID 或一个组名字符串。如果组名指定,本函数阻塞直到将它解析为一个数值 ID。


获取进程的用户标识。(参看 getuid(2)。)这是一个数值用户 id,不是用户名。
设置进程的用户标识。(参看 setuid(2)。)接收一个数值 ID 或一个用户名字符串。如果用户名指定,本函数阻塞直到将它解析为一个数值 ID。


返回一个保存补充组 ID 的数组。如果有效组 ID 被包含在内 POSIX 不管它让它未指定,但 node.js 确保它总是。
// 说明:不熟悉 POSIX,真心看不懂。
设置补充组 ID。这是一个特权选项,意味着你需要为 root 用户或拥有 CAP_SETGID 的能力。
列表可以包含组 ID,组名,或二者都包含。
使用用户名所在的所有组,读取/etc/group且初始化组可访问列表。这是一个特权选项,意味着你需要为 root 用户或拥有 CAP_SETGID 的能力。
user 是一个用户名或用户 ID。extra_group 是一个组名或组 ID。
当注销权限时需要注意。例子:
一个表示 NODE_VERSION 的编译进来的属性。
一个表示 node 和它的依赖的版本字符串属性。
将打印如下输出:


一个包含我们用来编译当前 node 可执行文件的配置选项的 JavaScript representation 的对象(//注:这里看不懂啥是 representation ,看英文吧)。这和运行 ./configure 脚本生成的“config.gypi"是一样的。
可能的输出例子如下:


发送一个信号给进程 pid。pid 为进程 id,signal 为描述发送的信号的字符串。信号名为形如 'SIGINT 或 'SIGHUP' 的字符串。如果省略,信号默认为 'SIGTERM'。更多信息参看 Signal Events 和 kill(2)。
如果目标进程不存在将抛出一个异常,且作为特例,信号 0 可以用来测试进程是否存在。
注意只是因为这个函数的名字是 process.kill,它实际上只是一个信号发送者,如同系统调用 kill。信号发送后可以做其它事情而不仅仅杀死目标进程。
发送信号给自己的例子:


注意:当 Node.js 接收到 SIGUSR1 它会启动调试器,参看 Signal Events。
进程的 PID。
用来设置在 ’ps' 中的显示什么的 getter/setter。
当作为 getter 使用时,最大长度由系统指定,有可能是很短的。
在 Linux 和 OS X 下,它受限于名字二进制大小加上命令行参数长度,因为它覆盖了参数内存。
v0.8 通过也覆盖环境内存允许更长的进程标题字符串,但那有潜在的不安全性/在某些情况下会混乱(不仅是模糊不清)。
你运行在什么处理器架构上:'arm','ia32',或 'x64'。
你运行在什么平台上:'darwin','freebsd','linux','sunos',或 'win32'。
返回一个描述 Node 进程内存使用的对象,单位是字节。
这将打印:
heapTotal 和 heapUsed 表示 V8 的内存使用。
在事件循环的下一次调用这个回调函数。这不仅是 setTimeout(fn, 0) 的别名,它更有效率。典型地它在任何其他的 I/O 事件之前运行,但有一些例外。参看下面的 process.maxTickDepth。
在开发 API 时若你想给用户机会去在对象被创建之后但在任何 I/O 发生之前分配事件监听器,这个函数是很重要的。


保证 API 是100%同步的或100%异步的是非常重要的。考虑下面的例子:


这个 API 是冒险的。如果你执行下面:
那么不清楚到底 foo() 还是 bar() 先被执行。
这个方法会更好:


● 数字类型 默认值 = 1000
传递给 process.nextTick 的回调函数通常会在当前的执行结束后才被调用,因此近似于尽快地同步调用一个函数。不进行任何检验,这将有可能饿死时间循环,阻止任何的 I/O 调用发起。
考虑这样的代码:
为了避免 Node 被一系列递归 nextTick 无限循环锁阻塞,它会延迟来让一些 I/O 每隔一段时间被执行。
process.maxTickDepth 的值是 nextTick 调用 nextTick 回调函数的最大深度,以在允许其他形式的 I/O 发起前进行评估。
设置或读取进程的文件模式的创建掩码。子进程从父进程继承掩码。如果 mask 参数给出则返回就是掩码,否则返回当前的掩码。
Node 已经运行的秒数。
返回 [秒,纳秒] 的元组数组形式的当前高精度真实时间。它相对于过去的任意时间。它不是跟一天中的某个时间有关,因此不会受制于时钟偏移。主要的用途是测量某间隔间的程序执行。
你可以传递之前的调用结果给 process.hrtime() 来获得一个差异值,对基准和测量间隔很有用:

