天天看點

NODE.JS API —— PROCESS(程序)

// 說明

    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 的例子:

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    當一個異常一路冒泡到事件循環時發射。如果為這個異常添加了一個監聽器,那麼預設的動作(列印堆棧資訊并退出)将不會被觸發。

    監聽 uncaughtException 的例子:

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    注意 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 屬性:

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    更多資訊參看 tty 文檔。

    寫向标準錯誤輸出的可寫流。

    process.stderr 和 process.stdout 和 Node 中的其他流不同,向它們寫入通常是阻塞的。

    标準輸入的可寫流。

    打開标準輸入并監聽兩個事件的例子:

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    作為一個流,process.stdin 也可以用于“老”模式,那是為了相容使用 v0.10 之前的 node 所寫的代碼。更多資訊參看流相容性。

    在“老”模式下标準輸入流預設是暫停的,是以必須調用 process.stdin.resume() 來從從裡面讀取。而且需要注意調用 process.stdin.resume() 本身會将流選擇為“老”模式。

    如果你正在啟動一個新項目,你應該選擇更現代的“新”流模式而不是“老”的。

    一個包含指令行參數的數組。第一個元素為 'node',第二個元素為 JavaScript 檔案名。剩下的參數為附加的指令行參數。

    輸出将會是:

    這是啟動程序的可執行程式的絕對路徑。

     例子:

    這是啟動程序的可執行程式的 node 特殊的指令行參數集。這些選項不會在 process.argv 出現,且不會包括 node 可執行程式,腳本名,或任何在腳本名後的選項。當為了使用父程序同樣的執行環境建立子程序,這些參數是有用的。

    例子:

    process.execArgv 的結果:

   process.argv 的結果:

    這會導緻 node 發射一個 abort。這回引起 node 退出并建立一個核心檔案。

    改變程序的目前工作目錄或如果失敗則抛出一個異常。

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

   傳回程序的目前工作目錄。

    一個包含使用者環境的對象。參看 environ(7)。 

    使用指定的 code 停止程序。如果省略,使用“成功”碼 0 退出。

    使用一個“失敗”碼退出:

    執行 node 的 shell 将看到1作為退出碼。

    注意:這個函數隻在 POSIX 平台下可用(也就是 Windows 不能使用)

    擷取程序的組辨別。(參看 getgid(2)。)這是數字組 id,不是組名。

    設定程序的組辨別。(參看 setgid(2)。)接收一個數值 ID 或一個組名字元串。如果組名指定,本函數阻塞直到将它解析為一個數值 ID。

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    擷取程序的使用者辨別。(參看 getuid(2)。)這是一個數值使用者 id,不是使用者名。

    設定程序的使用者辨別。(參看 setuid(2)。)接收一個數值 ID 或一個使用者名字元串。如果使用者名指定,本函數阻塞直到将它解析為一個數值 ID。

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    傳回一個儲存補充組 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.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    一個包含我們用來編譯目前 node 可執行檔案的配置選項的 JavaScript representation 的對象(//注:這裡看不懂啥是 representation ,看英文吧)。這和運作 ./configure 腳本生成的“config.gypi"是一樣的。

    可能的輸出例子如下:

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    發送一個信号給程序 pid。pid 為程序 id,signal 為描述發送的信号的字元串。信号名為形如 'SIGINT 或 'SIGHUP' 的字元串。如果省略,信号預設為 'SIGTERM'。更多資訊參看 Signal Events 和 kill(2)。

    如果目标程序不存在将抛出一個異常,且作為特例,信号 0 可以用來測試程序是否存在。

    注意隻是因為這個函數的名字是 process.kill,它實際上隻是一個信号發送者,如同系統調用 kill。信号發送後可以做其它事情而不僅僅殺死目标程序。

    發送信号給自己的例子:

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    注意:當 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 發生之前配置設定事件監聽器,這個函數是很重要的。

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

   保證 API 是100%同步的或100%異步的是非常重要的。考慮下面的例子:

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    這個 API 是冒險的。如果你執行下面:

    那麼不清楚到底 foo() 還是 bar() 先被執行。

    這個方法會更好:

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

    ● 數字類型 預設值 = 1000

    傳遞給 process.nextTick 的回調函數通常會在目前的執行結束後才被調用,是以近似于盡快地同步調用一個函數。不進行任何檢驗,這将有可能餓死時間循環,阻止任何的 I/O 調用發起。

    考慮這樣的代碼:

    為了避免 Node 被一系列遞歸 nextTick 無限循環鎖阻塞,它會延遲來讓一些 I/O 每隔一段時間被執行。

    process.maxTickDepth 的值是 nextTick 調用 nextTick 回調函數的最大深度,以在允許其他形式的 I/O 發起前進行評估。

    設定或讀取程序的檔案模式的建立掩碼。子程序從父程序繼承掩碼。如果 mask 參數給出則傳回就是掩碼,否則傳回目前的掩碼。

    Node 已經運作的秒數。

    傳回 [秒,納秒] 的元組數組形式的目前高精度真實時間。它相對于過去的任意時間。它不是跟一天中的某個時間有關,是以不會受制于時鐘偏移。主要的用途是測量某間隔間的程式執行。

    你可以傳遞之前的調用結果給 process.hrtime() 來獲得一個差異值,對基準和測量間隔很有用:

NODE.JS API —— PROCESS(程式)
NODE.JS API —— PROCESS(程式)

繼續閱讀