Swoole協程之旅-前篇
寫在最前
Swoole協程經歷了幾個里程碑，我們需要在前進的道路上不斷總結與回顧自己的發展歷程，正所謂溫故而知新，本系列文章將分為協程之旅前、中、後三篇。
- 前篇主要介紹協程的概念和Swoole幾個版本協程實現的主要方案技術；
- 中篇主要深入Zend分析PHP部分的原理和實現；
- 後篇主要補充和分析協程4.x的實現。
軟文正式開始
協程是什麼？
概念其實很早就出現了，摘wiki一段：According to Donald Knuth, the term coroutine was coined by Melvin Conway in 1958, after he applied it to construction ofan assembly program.The first published explanation of the coroutine appeared later, in 1963. 協程要比c語言的歷史還要悠久，究其概念，協程是子程式的一種， 可以通過yield的方式轉移程式控制權，協程之間不是呼叫者與被呼叫者的關係，而是彼此對稱、平等的。協程完全有使用者態程式控制，所以也被成為使用者態的執行緒。協程由使用者以非搶佔的方式排程，而不是作業系統。正因為如此，沒有系統排程上下文切換的開銷，協程有了輕量，高效，快速等特點。（大部分為非搶佔式，但是，比如golang在1.4也加入了搶佔式排程，其中一個協程發生死迴圈，不至於其他協程被餓死。需要在必要的時刻讓出CPU,Swoole在V4.3.2增加了這個特性）。
協程近幾年如此火爆，很大一部分原因歸功與golang在中國的流行和快速發展，受到很多開發的喜愛。目前支援協程的語言有很多，例如： golang、lua、python、c#、javascript等。大家也可以用很短的程式碼用c/c++擼出協程的模型。當然PHP也有自己的協程實現，也就是生成器，我們這裡不展開討論。
Swoole1.x
Swoole最初以高效能網路通訊引擎的姿態進入大家視線，Swoole1.x的編碼主要是非同步回撥的方式，雖然效能非常高效，但很多開發都會發現，隨著專案工程的複雜程度增加，以非同步回撥的方式寫業務程式碼是和人類正常思維相悖的，尤其是回撥巢狀多層的時候，不僅開發維護成本指數級上升，而且出錯的機率也大幅增加。大家理想的編碼方式是：同步編碼得到非同步非阻塞的效能。所以Swoole很早的時候就開始了協程的探索。
最初的協程版本是基於PHP生成器GeneratorsYield的方式實現的，可以參考PHP大神Nikita的早期部落格的關於協程 介紹。PHP和Swoole的事件驅動的結合可以參考騰訊出團隊開源的TSF 框架，我們也在很多生產專案中使用了該框架，確實讓大家感受到了，以同步程式設計的方式寫非同步程式碼的快感，然而，現實總是很殘酷，這種方式有幾個致命的缺點：
- 所有主動讓出的邏輯都需要yield關鍵字。這會給程式設計師帶來極大的概率犯錯，導致大家對協程的理解轉移到了對Generators語法的原理的理解。
- 由於語法無法相容老的專案，改造老的專案工程複雜度巨大，成本太高。
這樣使得無論新老專案，使用都無法得心應手。
Swoole2.x
2.x之後的協程都是基於核心原生的協程，無需yield關鍵字。2.0的版本是一個非常重要的里程碑，實現了php的棧管理，深入zend核心在協程建立，切換以及結束的時候操作PHP棧。在Swoole的文件中也介紹了很多關於每個版本實現的細節，我們這篇文章只對每個版本的協程驅動技術做簡單介紹。原生協程都有對php棧的管理，後續我們會單獨拿一片文章來深入分析PHP棧的管理和切換。
2.x主要使用了setjmp/longjmp的方式實現協程，很多C專案主要採用這種方式實現try-catch-finally，大家也可以參考Zend核心的用法。setjmp的首次呼叫返回值是0，longjmp跳轉時，setjmp的返回值是傳給longjmp的value。 setjmp/longjmp由於只有控制流跳轉的能力。雖然可以還原PC和棧指標，但是無法還原棧幀，因此會出現很多問題。比如longjmp的時候，setjmp的作用域已經退出，當時的棧幀已經銷燬。這時就會出現未定義行為。假設有這樣一個呼叫鏈：
func0() -> func1() -> ... -> funcN()
只有在func{i}()中setjmp，在func{i+k}()中longjmp的情況下，程式的行為才是可預期的。
Swoole3.x
3.x是生命週期很短的一個版本，主要借鑑了fiber-ext 專案，使用了PHP7的VM interrupts機制，該機制可以在vm中設定標記位，在執行一些指令的時候（例如：跳轉和函式呼叫等）檢查標記位，如果命中就可以執行相應的hook函式來切換vm的棧，進而實現協程。雖然我們完整的實現了協程的功能，但是由於並沒有相對2.x有很大的進步，原因我們後續的文章會做進一步分析，所以我們放棄了這個版本，直接進入了4.x的版本迭代。
Swoole4.x
4.x協程是當前Swoole的協程版本，借鑑了前面版本的缺點和問題，引入了PHP
+C
雙棧管理維護，完美的支援PHP各種語法，詳細分析我們放在系列文章最後。
End
協程之旅前篇結束，下一篇文章我們將深入Zend分析Swoole原生協程PHP部分的實現。