開源一個超簡單的無棧協程原型（終）

有的同學認為我的東西過於簡單，沒什麼大用。分享一個超超超超輕量級的stackless協程框架

其實我並不反對我的東西很簡單，如他所述，yuanzhubi/coroutine_proto真的就只是一個協程原型， 並沒有使用任何general 的CPS之類的通用解法的來秀技。

但是我們所有的方案都是來解決問題的，我們的問題是什麼？

我的問題是：當你發現自己「暫時無法執行下去」的時候（從順序執行，條件執行，循環執行說起（0）），需要不是就地傻等，而是給一個自然的」執行路徑「，避免阻塞在tcp的connect里, 阻塞在recv數據里，阻塞在等待鎖釋放里，，，做到這一切的同時」阻塞等待「的語法盡量少修改。有棧協程配合動態庫hook甚至可以做到二進位級別無修改（參見libco,libgo）。

是的，咱們中國人總是會遇到和我們談歷史的人，遇到啥的時候總是免不了加幾句，」這火藥咱們祖宗早就發明過了，炸藥有啥用啊，還不是硝石炮製幾下。。「，」這個協程幾十年前就發明了，不就是達夫設備switch嘛。。「，」一級可continue對象，你懂嗎？這幾份論文讀過嗎。。「，」沒有實現CPS的肯定邏輯不自洽，遞歸絕對會出問題「。。。

沒錯，歷史已經存在在那裡了，但是歷史卻遠遠不能預測到我們現在所要面對的問題。幾十年前的協作運行操作系統所面對的問題複雜性也遠遠不能和我們如今複雜的訴求能夠相比。「暫時無法執行下去」的原因複雜多了，僅僅提供一個generator模式遠遠無法滿足我們的使用和配合調度器工作。更何況如今軟體工程師和軟體數量比過去大多了，提供一套易用而又高效還要易懂的介面也是非常重要的。

我們是面向問題來提供最合適的解決方案，而不是遵循歷史對協程的定義去強行把腳削了塞到古墓里的鞋子去。開源一個超簡單的無棧協程原型（2） 此文中，我也特意把問題原型回到了幾十年前那種cpu如同如今的IO一樣，操作受限的情況，可以從歷史的角度上來觀看我們現在問題所處的角度。

」...做到這一切的同時」阻塞等待「的語法盡量少修改....「 是的，為了解決這個問題，我選擇了await這個最早我從微軟見到的關鍵字來描述，」假等待「這個概念和整套方案: 你認為他在等待的時候，他返回了；你認為他返回的時候，他實際上是被調用了。中間這個時間差就讓代碼逃離了本來會阻塞的場景。

」...易用而又高效還要易懂的介面...「, 易用性是眾口難調的，我在開源一個超簡單的無棧協程原型（５） 也提到了，我選擇了類似阻塞API的方式，調用出錯會選擇已錯誤碼通知的方式進行投遞而不是異常投射。」高效「，我首先保證內存盡量節省使用，其次await和resume要高效快捷，提供類似尾遞歸的優化介面，單await和並發await分開處理。最後，」易懂「，面向我們要解決的問題（前後台的各種」暫時不行「問題）提解決方案，輕易不引入新概念和新術語， 確定好設計邊界之後抽象我們的問題和解決方案的原型，先不過度考慮如何general化。

最後回答一位評論者的問題：」開源一個超簡單的無棧協程原型「 系列的（1） 在哪裡？其實本系列是回應7個月前的一個坑，介紹一下call_in_stack(1) 裡面本來要實現並開源一個有棧協程的（x86&x64），但是那個被工作中用起來了，就不太方便開源了（yuanzhubi/coroutine_proto 這個地址最早的描述都是有棧協程的原型的）。所以又寫了這個無棧協程來給觀眾們賠罪。 謝謝大家的關注。