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 中实现完整的协程支持。