兩種運行時 -- 寫於2009-05-19

這一篇的動機是忽然想到在我上一篇博文中提到的使用「截棧」方式實現的分階段工做模型中，若是把一個階段看做是一個工做單元，那麼這個工做單元與函數式編程中的工做單元--函數是能夠徹底等同起來的。 由於，FP的工做模型是「接力」。在這種工做模型中，全部的工做單元是平等的。工做在總體上是經過平等的工做單元--「函數」所完成的。 而若是咱們對一個長調用進行「截棧」之後，方法調用將在截斷位被停止。所以，被截開的棧與棧之間已經不存在原來意義上的「調用」關係。 由於採用「截棧」模型的運行時無論其如何管理棧（好比，爲不一樣的階段分配不一樣的棧；或者對棧進行重用---這其實正是分階段的真正目的。即經過分階段實現了棧的快速回收。咱們老是嘲笑那種撿了芝麻，丟了西瓜的人。然而不把西瓜丟掉，撿芝麻就不方便。這不正是咱們現正的問題嗎？），一個屬於已完成（指已經往約定的地址輸出了本身的結果）階段的棧必須被丟棄---或回收。 而傳統調用模型是基於服務的同步調用。且這種同步調用理論上是無止境的。也就是說，歷來沒有任何東西被設計用來中止它。除非遇到了內存邊界（人爲的或機器的）！但被「截棧」之後的程序，顯然，或者說最少，無止境的同步調用從設計上被「取消」了。一個被取消了無止境同步調用的工做模型，顯然爲異步的介入提供了機會（慶祝！）。且一旦引入了「截棧」的概念，本來受到物理內存限制的最大棧長再也不存在。由於「截棧」雖然表面上看起來仍然是一種人爲設定內存邊界的的手段，好象與原來的模型並無什麼區別，但這只是單個「截棧」的狀況。當咱們把眼光再放寬一點，即假設咱們如今看到了多個「截棧」，那麼，如今的狀況還與原來同樣嗎？ 固然不。一個棧與多個棧的區別實在是太大了！ 在「一棧到底」的工做模型中，棧空間的釋放必須發生在整個工做被完成之後； 而在多棧模型中，由於工做被分紅了幾個階段來完成。任何一個階段的完成都意味着一個棧空間的釋放（或可釋放）。因此，理論上，任意長度的一個工做均可以使用兩個棧完成！（這個討論開始變得有點意思了。。。由於以前我一直在懷疑這種模型即「截棧」與如今最流行的異步模型有什麼區別。甚至剛纔還提醒本身記得在此文最後對如今的異步模型做一下理論迴歸。如今看來徹底沒有必要。由於異步模型強調的是合做，基礎仍然是基於服務的調用。只不過這種調用從同步變成了異步而已。二者之間根本就不存在任何聯繫！） 延續式調用與服務型調用其實在函數（除指令之外最小的工做單元）內部與長期狀態保留中使用的分別應該是相同的內存模型-棧與堆。應爲不論是任何語言，顯然不會使用一個不能直接尋址的內存模型-堆-去保存一串定長的數據（計算機很難離開固定長度的數據進行工做。好比，雖然對象是不定長的，但其指針是定長的）。所以，延續式調用與服務型調用之間惟一的區別其實只是在於函數自己的內存模型。服務型調用在函數之間仍然使用與函數內相同的內存模型-「棧」。只不過，這裏所講的「棧」象函數同樣，是對最小的工做單元（內存字）的第一層抽象。 1, what's good for continuation? 2, what's good for staging? 3, what's good for asynchronization?