2012年7月7日 星期六

Node.js v0.8 大變革?!Native Module 開發者的福音!

Standard
最近 Node.js 推出了 v0.8 穩定版,除了改善 I/O 的效能和一些 API 外,最大的變動就是跨平台開發環境的改進。包括了決定徹底使用 GYP 取代 node-waf(wscript)、宣布 libev 將死。或許,這些變動這對大部份的 Node.js 使用者來說不是什麼問題,但對於我們這些寫 Native API 和底層的開發者來說,關係到自己程式能不能跑在未來 Node.js 的新版本上,而且產生了很多移植性的工作。但是整體來說,好處其實大於壞處,因為以後我們的程式更容易跨平台了。

轉用 GYP

GYP 是 Google 發展出來的 Build script tools,就像是傳統 Autotools、Makefile 或 CMake 這類的工具。GYP 最早被應用在廣為人知的 Google Chrome/Chromium Project ,是個跨平台的解決方案,這也是為什麼 Node.js 決定要採用的主要原因。

在以前,不同的平台上,你需要為 C/C++ Addon 製作不同的 Build script,沒有統一的方法和途徑去設置和編譯程式,這讓跨平台的工作非常麻煩。使用 GYP 後,可以大幅減少這樣的問題。

棄 libev ,轉用 libuv

首先,有一點要注意,Node.js 開發者打算在下一個穩定版(應該是 v1.0)拿掉 libev 的支援,所以請所有的開發者盡快轉用 libuv。

libev 是 Node.js 在非 Windows 平台上所使用的 Event loop 解決方案,讓 C/C++ 開發者可以開發 Event-driven 的程式,除了可以用來監聽 FileSystem 等用途,也更容易整合 Thread 進 Event-driven 的設計模式中,要是你有印象,GLib 其實也是類似的解決方案之一,只不過 libev 更為輕量。不過, libev 主要還是被應用在 Unix-like 的系統上,若 Node.js 要支援多個平台,在其他系統上,就必需尋求別的解決方案,如 Windows 的 IOCP。

而過去這樣的情況,對我們 Node.js Native Module 開發者來說,是個莫大的挑戰,你必需在不同系統上,採用不同的寫法,導致開發上很困難。所以 Node.js 自行開發了 libuv,包裝了 libev 和 IOCP 等機制,讓所有的開發者,只要統一使用 libuv API 即可,不用再管跨平台的問題。

換句話說,如果你直接使用 libuv,在 Linux 等 Unix-like 的系統上,其底層依然還是使用 libev,如果你是在 Windows 上,則底層會使用 IOCP。所以,與其說是棄 libev,其實是避免開發者直接使用它。

libuv 直接支援 Thread 操作

在 Node.js v0.6 以前,libuv 還並不支援直接的 Thread 操作,若你要達成這樣的需求,只有使用 uv_queue_work() 去模擬,不然就是要使用作業系統原生的 Thread API。不過,若直接使用作業系統原生的 Thread API,也同樣有跨平台的問題存在,所以 libuv 在新版中已經提供 Thread 的包裝 uv_thread_t,也提供相關的 API,讓開發者使用。