关于现有项目与腾讯Libco协程库无缝衔接的研究（2）

问题：

上篇文章提到了使用libco对现有项目进行改造的研究，但真的要实现libco的无缝衔接，对于很多后端c/c++项目而言，还存在以下问题要解决。

1.针对已有的采用同步编程的程序，可以简单使用libco进行改造，基本没有什么大问题，本文不再做讨论。

2.考虑到程序运行效率，大多数后端程序已经采用了异步编程，而且很多三方库如c的libev、libuv、libevent，c++有asio等等都已经很成熟，很多公司的底层框架已经与它们融为一体。

异步结合libco的使用场景：

考虑实时交互系统中，如果A、B两个微服务，场景是用户X发请求给A服务，A处理业务请求期间与B交互得到结果，最终A返回应答信息给X用户。

一般的异步编程认为，A接收到请求，然后异步请求B，将后续的处理逻辑各对用户X的应答放在对B请求的回调里，由异步触发。

现在新上线了一个C服务，用户X发请求给A服务，A处理请求期间先与C服务交互得到结果，然后再与B交互得到结果，最终A返回应答信息给X用户，程序要怎么改...

现在又上线了一个D服务，用户X发请求给A服务，A处理请求期间先与D服务交互得到结果，然后再与C服务交互得到结果，然后再与B交互得到结果，最终A返回应答信息给X用户，程序要怎么改...

......

如果引入协程的话，改造形式就如同：A先与D交互“等”返回，后再与C交互“等”返回，再与B异步交互（这里是原有项目代码，不用改）返回，同步代码一写到底，实际上每个“等”都是异步。

难点：

目前项目引入libco会造成困难，难点有以下几个：

1.libco协程使得程序员可以以同步编程的方式写异步代码，与现有的异步编程融合时，在代码的可读性方面容易引起一些困惑。

2.现有的libco自有异步循环，与目前项目所使用的不一致，两部分代码衔接方面存在问题。

3.协程融入现有异步程序后，现有项目要考虑到协程引入的一些问题，一个常见的问题就是，在协程的切换动作之前和之后程序员要考虑到有些全局状态可能已经被其它协程所修改。

解决办法：

修改libco源码，抽象出第三方事件库的接口，使得libco协程库可以自由地嵌入第三方事件库如libev、libuv、libevent所写的现有项目中去，改造后分享项目如下：https://github.com/klavien/libcoevent

目前该库已支持libev、libae（redis内部使用）

libuv、libuv支持中，asio...这个是大头..