关于Coroutine
说到coroutine就不的不说subroutine，也就是我们常用到的一般函数。调用一个函数开始执行，然后函数执行完成后就退出，再次调用的时候，再从头开始，调用之间是没有保存状态的；但是coroutine是可以在退出时如果再次被调用，可以从上一次退出的点继续执行。也就是说coroutine的调用之间是会保存状态的。如果有多个coroutine，就可以反复调用，但是两个coroutine相互前进。当一个coroutine退出时，不是return，而是yield，表示把当前的执行权交由下一个coroutine处理，或者交出一个结果值。coroutine与我们常用到的thread有点类似，一个thread会执行一个我们指定的函数，然后当该函数调用一个阻塞IO或者同步等待一个事件或者消息时，就会被操作系统调度到等待队列，当完成或者事件响应后，线程就会继续从等待的地方执行。thread和coroutine最大的区别就是调度方式的区别，前者一般都是基于时间片的抢占式调度，而coroutine都是协作式调度。
话说回来，我们一般用的函数可以很容易的转换到coroutine。coroutine中还有一个特例，就是generator. Generator可以像一般的coroutine一样从上一次返回的地方继续执行，也可以yield多次，也可以把自己挂起，但是一般的coroutine可以在yield时指定下一个要执行的coroutine，而generator不能这么做。因此，generator一般用来实现迭代器。
Coroutine可以很方便的用来实现状态机。 Coroutine实现状态机会让代码变的更可读。比如实现一个SMTP客户端，用的是event-driven范式实现，那么就需要记录每次处理的状态，代码会变得异常复杂。假设你还是使用的event-driven范式实现，但是你用到了coroutine，coroutine内部的流程就是一般SMTP的流程，只是需要每一步请求发送后就退出，然后当收到回应包时event-driven引擎又再次调用了你的coroutine，直接到了上一次退出的地方，是不是感觉更清爽？
因为coroutine比thread相比要轻量的多，thread在操作系统层面实现，调度方式涉及到CPU上下文的切换，和coroutine的协作式调度相比要重了一些，在高并发场景中针对每个请求用thread承载会变的非常低效，但是coroutine反而容易在语言层面或者库层面实现，因此调度代价要低很多。像Lua的coroutine实现要求程序员自己调用yield自己调度，比较麻烦，但是假设像Golang，Erlang等语言把显示的协作调度隐藏起来，让程序员专注功能实现，会更容易让人接受。在golang中叫coroutine叫goroutine，当goroutine中调用了阻塞操作或者Channel的读写操作时，就会导致对应的goroutine得到执行，当完成后又会被调度回来继续执行，这种同步的编程方式可以让并发场景进行简化，让逻辑变得更清晰。Golang的这种实现把一般的显示的协作调度隐藏起来，更容易被程序员接受。
C语言实现的Coroutine
一般Coroutine多在带有GC机制的语言中实现，像在C/C++下实现coroutine会比较复杂和麻烦，不过还是有很多不同的实现，比如Russ Cox实现的libtask库，C++下的boost.coroutine库等等。其中我觉着最亮的是 大牛Simon Tatham（putty的作者）基于Duff's Device实现的版本《Coroutine in C》。其中展示了如何把一个复杂的decompressor用coroutine简化的。Simon大神实现了两种coroutine，一种是基于static变量保存状态的，另外一种是通过参数传递一个指针的指针保存状态的。后者更通用一些。详细代码点击这里。
boost.asio.coroutine
asio中的coroutine的实现与上面Simon的第一种实现一样。所以没有太多可说的。boost.asio.coroutine的使用非常简单，在自己代码中包含coroutine.hpp和yield.hpp，创建一个类，派生自coroutine类。然后可以根据自己的业务要求写相应的coroutine了。当然，也可以把coroutine类作为自己的成员变量组合到自己的类中。
asio的作者也对其做了详细的说明《A potted guide to stackless coroutines》，同时还写了专门个使用指南《Composed operations, coroutines and code makeover》。
总结
想用Coroutine建议还是用些现代的新语言吧，比如Golang, Erlang, Scala等。