libco采访提纲

未分类

在腾讯的《解密：微信如何用libco支撑8亿用户？》一文的基础上，InfoQ的采访提纲如下：

微信后端都是使用C++语言开发的吗？有其他语言吗？占比多少？当初为什么选择C++？

能否详细介绍下Libco产生的背景？为什么你们会开发Libco？

协程Coroutine并不是新的概念，但是最近几年在某些语言中得到广泛应用。能否根据你们的经验和体会，谈谈你们的看法？
（因为协程并不是很广为人知，建议简单介绍下，可以通过打比方、与线程类比先来讲解下协程的概念，然后再谈看法）

简单来说，Libco是为了提升微信后台的并发能力而设计的。从现在你的角度来看，解决这个问题还有哪些可以选择的解决方案？各有什么优缺点？
（如果能有Libco相对于微信后端整体架构的关系是示意图就更好了。）

因为不想“从框架到业务逻辑代码的彻底改造”，微信选择了保持类似同步变成风格。那有没有估算这个方案与其他方案（异步模型），在产生代码复杂程度上的对比情况？（简单估算或者直观例子均可）

能否介绍下Libco架构的演变过程？架构有哪几层，主要是如何分工的？
（这里会附上当前的Libco架构图，腾讯微信文中的有水印，麻烦给一张原图哈

Libco有什么特别设计之处吗？对于同步风格的API，Libco是如何处理的？

Libco的结合使用了协程的共享运行栈、协程的私有变量和私有内存，对于三个Libco的核心技术，调用者需要怎样的管理，使用过程中有哪些注意事项？

能否阐述共享栈模式原理？
（怎样从堆上分配协程的运行时所需内存？不同协程之间的切换、如何主动退出一个正在执行的协程？有汇编代码的修改吗？）

这个库对底层的适应有无特殊需求？修改 glibc 的 gethostbyname 是否会影响移植性？

与线程相比，在使用协程的情况下，怎样可以充分利用多核CPU的？（协程毕竟还是运行在一个真实线程中？）

协程库的一个问题就是对于已有的库的支持，一些老的库中可能还是通过同步的 io 的 api 操作，如果在协程中调用这些历史遗留的库会不会造成协程库本身的 n:m 调度器的线程阻塞，比如 python 的 gevent 提供了 monkey patch 之类的机制改造标准库中的同步语义的 api，但是在一个静态语言中应该是很难的吧？请问 Libco 对这个问题有考虑吗？