libco和tornado、协程和异步的一些理解

看了些libco的实现，感觉和tornado差不多，基本的思想还是在线程被阻塞的时候能够去做其他的事情，此时还是用epoll来调度挂起和恢复

从这点看协程依然是基于异步的，且是纯异步的，只是协程框架提供了更好的语义表达，代码书写更方便了，因此，协程的使用也是用在有一定的IO的服务中，纯计算的服务用起来并不合适。这样来看，协程和线程的使用场景不同，说协程是用户态线程容易误导人

libco和tornado比较，有以下特点：

1 python的多线程效率太低，所以tornado只能是多进程的，libco用c++实现，则是可以用于线程中的

2 libco实现了栈内存hook，引入了共享栈，优化了协程切换的内存拷贝；tornado基于python的内存管理，有gc的语言确实很方便，使用future机制

3 libco也hook了系统IO函数，这样用于开发更方便；tornado则需要自己来维护和写异步过程，尤其是用第三方rpc客户端的时候

4 libco的异步调度器是每毫秒扫一次定时器组，定时器组是一个固定大小的数组，数组元素是个拉链，每个定时器放在和定时器组当前时间差值的位置，所以不能设置太大的超时时间，默认最大是一分钟；tornado是以定时器的deadline（now+timeout）为key，将定时器组维护成了一个最小堆，异步调度器每次获取最小的定时器，以其deadline-now作为调度器的超时时间，等待调度器超时或者响应了事件之后再扫描定时器组执行

两者类似，都是牺牲了平均延迟时间，增加qps；每个异步过程（协程）占用CPU时间不能太长，需要分片主动让出cpu

libco的作用：

1 优化常用的异步IO+多线程(多进程）的服务（服务要有下游IO），这类服务的线程在与下游IO的时候还是会有一段时间段的阻塞，也就是没事干；协程可以充分利用这段时间

2 方便对mc，redis等第三方访问的异步，不然自己要从客户端源码中抽取也要费很大力气，还得搞很多状态维护

2017/06/02

看了一些协程的介绍文章，协程更多的是一种机制理念，描述为用户态线程，和异步的区别在于主动保存当前栈上下文

但是最适合的使用场景仍然是在IO，所以最终的实现原理和异步差不多

2017/06/05：

协程的另一种应用场景是类似python中的yield，也有其他语言的类似实现，不过这种方式对性能有什么影响？

看到一个函数：pthread_attr_setstack ，这个函数可以实现对线程栈内存的hook，为什么不使用这个方式来实现协程呢，libco目前的做法有什么好处？

阿拉啦~