fiber/纖程

在操作系統中，除了進程和線程外，還有一種較少應用的纖程（fiber，也叫協程）。纖程常常拿來跟線程做對比，對于操作系統而言，它們都是較輕量級的運行態。通常認為纖程比線程更為輕量，開銷更小。不同之處在于，纖程是由線程或纖程創建的，纖程調度完全由用戶代碼控制，對系統內核而言，是一種非搶占性的調度方式，纖程實現了合作式的多任務；而線程和進程則受內核調度，依照優先級，實現了搶占式的多任務。另外，系統內核是不知道纖程的具體運行狀態，纖程的使用其實是比較與操作系統無關。

在node中，單線程是僅針對javascript而言的，其底層其實充斥著多線程。而如果需要在javascript中實現多線程，一種常見的做法是編寫C++ addon，繞過javascript的單線程機制。不過這種方法提升了開發調試的難度和成本。像其他很多腳本語言，我們也可以把纖程的概念引入到node中。

node-fibers

node-fibers這個庫就為node提供了纖程的功能。多線程方面沒有測試出理想的結果，不過在異步轉同步作用顯著，也許在減少node調用堆棧、無限遞歸方面也會有價值可挖。本文檔主要介紹 node-fibers庫的使用方法和異步轉同步等內容。

安裝

node-fibers是采用C語言編寫，直接下載源碼需要編譯，通常直接npm安裝即可：

fibers庫的使用

API

1.Fiber(fn)/ new Fiber(fn):

創建一個纖程，可以當成構造函數使用，也可以當成普通函數調用。如下例：

當 run()調用的時候，纖程啟動，并為 fn分配新的堆棧， fn會在這個新的堆棧上運行，直到 fn有返回值或調用 yield()。 fn返回后或調用 yield()后，堆棧重置，當再次調用 run()時，纖程會再次啟動， fn運行于首次分配的堆棧中。

2.Fiber.current:

獲得當前纖程，并可對其進行操作。如果指定一個變量與其相關聯，請務必確保此纖程能夠釋放，否則V8的垃圾回收機制會一直忽略這部分的內存，造成內存泄漏。

3.Fiber.yield(param):

前面的說明中已經提及過這個函數。 yield()方法用于中斷纖程，一定程度上類似 return。一旦執行 yield()，則此 Fiber中后續代碼將沒有機會執行，例如：

執行后只會輸出“Fiber Start”，后一個輸出命令沒有執行。如果向 yield()傳入參數，那么此參數作為 run()的返回值。

4.Fiber.prototype.run(param):

這個方法已經很熟悉了，之前隱約有提及調用 run()的兩種時態，一是Fiber未啟動時，一時Fiber被yield時。在這兩種時態下， run()的行為并不太一樣。
當Fiber未啟動時， run()接受一個參數，并把它傳遞給 fn，作為其參數。當Fiber處理yielding狀態時， run()接受一個參數，并把它作為 yield()的返回值，fn并不會從頭運行，而是從中斷處繼續運行。關于 fn、 yield、 run三者的參數、返回值等關系，可以通過下面的小例子來說明：

輸出如下：

從上面例子中，可以很明顯看出 yield的使用方法與現在的javascript的語法相當不同。在別的語言中（C#、Python等）已經實現了 yield關鍵字，作為迭代器的中斷。不妨在node上也實現一個迭代器，具體體會一下 yield的使用。還是以開頭的斐波那契數列為例：

輸出為：

有兩個問題需要留意，第一， yield說是方法，更多地像關鍵字，與 run不同， yield不需要依托Fiber實例，而 run則需要。如果在Fiber內部調用 run，則一定要使用： Fiber.current.run()；第二， yield本身為javascript的保留關鍵字，不確定是否會、何時會啟用，所以代碼在將來可能會面臨變更。

5.Fiber.prototype.reset():

我們已經知道Fiber可能存在不同的時態，同時會影響 run的行為。而 reset方法則不管Fiber處理什么狀態，都恢復到初始狀態。隨后再執行 run，就會重新運行 fn。

6.Fiber.prototype.throwInto(Exception):

本質上 throwInto會拋出傳給它的異常，并將異常信息作為 run的返回值。如果在Fiber內不對它拋出的異常作處理，異常會繼續冒泡。不管異常是否處理，它會強制 yield，中斷Fiber。

future庫的使用

在node中直接使用Fiber并不一直是合理的，因為Fiber的API實在簡單，實際使用中難免會產生重復冗長的代碼，不利于維護。推薦在node與Fiber之間增加一層抽象，讓Fiber能夠更好地工作。 future庫就提供了這樣一種抽象。 future庫或者任何一層抽象也許都不是完美的，沒有誰對誰錯，只有適用不適用。比如， future庫向我們提供了簡單的API能夠完成異步轉同步的工作，然而它對封裝 generator （類似上面的斐波那契數列生成器）則無能為力。

future庫不需要單獨下載安裝，已經包含在 fibers庫中，使用時只需要 var future=require('fibers/future') 即可。

API

1.Function.prototype.future():

給 Function類型添加了 future方法，將function轉化成一個“funture-function”。

實際上 power方法是在Fibel內執行的。不過現有版本的 future有bug，官方沒有具體的說明，如果需要使用此功能，請刪除掉 future.js的第339行和第350行。

2.new Future()

Future對象的構造函數，下文詳細介紹。

3.Future.wrap(fn, idx)

wrap方法封裝了異步轉同步的操作，是 future庫中對我們最有價值的方法。 fn表示需要轉換的函數， idx表示 fn接受的參數數目，認為其 callback方法為最后一個參數（這邊API的制定頗有爭議，有人傾向傳遞 callback應該處于的位置，好在 wrap方法比較簡單，可以比較容易修改代碼）?？匆粋€例子就能了解 wrap的用法：

從這個例子中可以看出Fiber異步轉同步確實非常有效，除了語法上多了一步 .wait()外，其他已經 fs提供的 fs.readFileSync方法別無二致了。

4.Future.wait(futures):

這個方法前面已經多次看到了。顧名思義，它的作用就是等待結果。如果要等待一個future的實例的結果，直接調用 futureInstance.wait()即可；如果需要等待一系列future實例的結果，則調用 Future.wait(futuresArray)。需要注意的是，在第二種用法中，一個future實例在運行時出現錯誤， wait方法不會拋出錯誤，不過我們可以使用 get()方法直接獲取運行結果。

5.Future.prototype.get():

get()的用法與 wait()的第一種方式很像，所不同的是， get()立刻返回結果。如果數據沒有準備好， get()會拋出錯誤。

6.Future.prototype.resolve(param1,param2):

上面的的 wrap方法總給人以一種 future其實在吞噬異步方法的回調函數，并直接返回異步結果。事實上 future也通過 resolve方法提供設置回調函數的解決方案。 resolve最多接受兩個參數，如果只傳入一個參數， future認為傳了一個node風格的回調函數，例如如下示例：

如果傳入兩個參數，則表示對錯誤和數據分別做處理，示例如下：

另外 future并不區分 resolve的調用時機，如果數據沒有準備好，則將回調函數壓入隊列，由 resolver()方法統一調度，否則直接取數據立即執行回調函數。

7.Future.prototype.isResolved():

返回布爾值，表示操作是否已經執行。

8.Future.prototype.proxy(futureInstance):

proxy方法提供一種 future實例的代理，本質上是對 resolve方法的包裝，其實是將一個instance的回調方法作為另一個instance的回調執行者。例如：

雖然執行的是 proxy，但是最終 target的回調函數執行了，并且是以 proxy的執行結果驅動 target的回調函數。這種代理手段也許在我們的實際應用中有很大作用，我暫時還沒有深入地思考過。

9.Future.prototype.return(value):

10.Future.prototype.throw(error):

11.Future.prototype.resolver():

12.Future.prototype.detach():

以上四個API呢我感覺相對于別的API，實際使用的場景或作用比較一般。 return和 throw都受 resolver方法調度，這三個方法都很重要，在正常的future使用流程中都會默默工作著，只是我沒有想出具體單獨使用它們的場景，所以沒有辦法具體介紹。 detach方法只能算 resolve方法的簡化版，亦沒有介紹的必要。