lua + libuv 的坑與爽

libuv 是大名鼎鼎的 nodejs 的底層庫。用 C 實現，代碼量不大，可是五臟俱全。比起同類項目 libevent 我更喜歡它簡潔的 API 接口。比 libevent 少了 httpserver 多了 subprocess 功能，封裝得很棒，免去了傳統的 fork 和 pipe 的不直觀的作法。

lua 能夠說是流行的腳本語言中：功能較強、代碼最少、性能較高、逼格很是高的腳本語言。設計得很優雅，關鍵字不多，這點和 golang 的思路很像。與 C 之間有可定製型極強的 API 交互接口。其實就是徹底暴露了整個 lua 虛擬機的接口，能夠自行構造任意的 lua 代碼和數據結構，極其強大好用。

這兩個項目結合在一塊兒，是頗有意思的。本質上至關於一個小型的 v8，lua 和 javascript 的特性仍是挺像的。在不涉及大量複雜運算，只是想用腳本的語言的特性作點快速開發的時候。這個組合是性價比至關高的。即使是涉及大量運算，也能夠選用 luajit，評測中它的大部分指標已經超過 v8 了。

把他們倆結合的時候，有一些爽點和坑點以下：

• libuv 凡是 handle 類型必需要調用 uv_close 關閉。否則會形成內存泄露。
• lua 和 C 的交互都是經過堆棧操做來進行的，和彙編有點像，一開始很容易弄錯參數位置，比較好的辦法是使用 pcall，在崩潰的時候打印出 traceback 和 stackinfo。
• 在最外層 uv_loop 中調用 lua 的時候，必須以調用一個 lua 函數開始。否則弄錯了參數個數就內存泄露了。lua 函數默認是有保護的，弄錯了也沒問題。
• 靈活的使用 lua 中的 userdata 能夠搞不少有意思的事情。好比說某個底層 C 模塊獲取了一個很大的 buffer，交給另一個底層 C 模塊處理。能夠把 C struct 包在 userdata 中在上層 lua 傳來傳去。相比之下 python 的 ctypes 比較臃腫複雜，功能簡單而不靈活。而 ctypes 還算比較好的設計了，通常腳本語言根本就壓根沒有這樣的概念，只是草草的給出動態庫的接口就了事了，徹底沒有精心設計和考慮過。
• lua_pushcclosure 是一個很不錯的設計。能夠把一個 C 函數和 lua 中的數個變量綁定起來做爲閉包，傳給 lua 調用。這點也是基本上秒殺其餘腳本語言的設計，配合 userdata 使用能完全解決了高層底層之間回調的各類糾葛。
• lua 數組下標默認從 1 開始是有緣由的。這樣經過 table.maxn 就能夠判斷 table 是做爲 dict 仍是 array 了。這點 php 作得就很差。
• uv_work 會自動建立線程池，默認 4 線程，所以不用擔憂效率問題。
• uv_process 退出的時候，進程和管道不必定誰先關誰後關，注意處理。
• lua_cjson 模塊是目前最快的（官網評測）json 模塊，通過分析它快的緣由是，邊 parse 邊在 lua 的虛擬機裏面生成各類結構。這也是別的腳本的第三方庫不可能作到的操做。它有多是腳本語言中最快的 json 模塊。
• http_parser 是比較快和輕量級的 http header parser，也是回調形式的庫，很容易和 libuv 結合到一塊兒，很容易就搞出一個 http client。
• luvit 是一個不錯的開源項目。
• 二者的文檔都挺豐富，libuv 能夠看《An Introduction to libuv》，講得很詳細。
• lua 的書是《Programming in Lua》，免費版沒有出到 5.2，5.2 和 5.1 有細節不同，參照官網的 《reference manual for Lua 5.2》。
• luajit 交叉編譯須要 gcc 4.7 以上的編譯器。而且支持 LARGER_FILE，在交叉編譯作工具鏈的時候要注意。