Python 協程：協程纔是將來 / 被線程替代 / 推與拉

協程三篇之一（協程初接觸）

協程雖然如此之好，看是很長時間以來，由於受到基於堆棧的子例程實現的限制，並無多少語言在其實語言或庫中支持協程，因此線程做爲一個替代者（固然，線程也有其超越協程之處）被普遍接受了。可是在今天，不少語言都內建了協程的支持，甚至是 C/C++ 語言。MS Windows 2000 之後的版本，都支持所謂的 Fiber，即纖程，其實就是協程的別稱；在開源平臺，POSIX 標準也定義了協程相關的標準，GNU Portable Threads 實現了跨平臺的用戶空間線程，即協程的另外一種別稱。在這百花齊放的時節，正是咱們好好學習和利用它的時機。

python 自身的協程實現？

我對於 python 的協程的觀點是：「python 自身已經提供了實現協程的基礎條件，是能夠很容易的實現概念中的協程。可是因爲棧的問題，只能由循環的方式來實現調用。而 stackless 在 python 原有的基礎上，改進了 python 在協程上的實現方式，使其代碼的表達更加的天然。」

協程纔是將來-性能誇張的協程服務器

下面給出一些對比數據，測試環境不一樣，可是數據不會相差太大：
一、大部分python web framework，600req/s
二、web.py，800req/s
三、曾經在土豆網用twisted寫的htmid框架，2300req/s
四、nginx+mod_wsgi，2900req/s
五、eventlet，約5800req/s

固然，如上的服務器功能確實少了點，可是提供了這樣一種基礎，方便之後擴展。記得N年前看過一篇論文說服務器的發展是多進程=>多線程=>異步=>協程。而如今主流的高性能服務器都是基於異步的(lighttpd、nginx)，此次試了一下協程，效果果真與衆不同。

協程和纖程

總的看來，協程有三個好處：

避免了傳統的函數調用棧，使得無限遞歸成爲可能
用戶態的線程調度，極大下降上下文切換的開銷，使得近乎無限併發的「微線程」成爲可能
因爲能夠在用戶態進行手工線程調度，這樣能夠避免鎖機制

其實這裏的「微線程」、纖程、協程，甚至用戶態線程，其實能夠理解爲都是一碼事，只是實現和概念的區別。

推與拉

Python 經過 yield 關鍵字既能夠方便的將數據推送給調用者，也能夠從調用者那拉來數據。實際上，yield 關鍵字只是協程（Coroutine）不徹底實現, 而協程偏偏是實現推拉互動的所謂非搶佔式協做的關鍵。不過，哪怕是不完整的實現，也讓 Python 在數據推拉相關的程序上的表達力豐富了許多，以致於不少人以爲有必要在 Python 中實現完整的協程支持。