@yulon 刚刚看到时确实比较惊讶，后来想了下，可能是代码贡献者当时想要省掉手写寄存器偏移地址的这个工作吧...

@wtcoder 十分感谢你的鼓励 ;-)

libaco 是开源的，热烈欢迎贵公司在生产环境中使用它，中间如果遇到任何的问题都可以发 Issue 大家一起来探讨哈 :D

@deadEgg 非常感谢你的支持 ;-)

> 现在做这个库是为了解决什么场景的问题呢。还是说去解决一些性能上的问题呢？

是的，主要是性能上的问题，但是，也可以认为是某种场景的解决方案。

场景：

高性能（应该接近极致）、高并发（百万数量级）和对内存使用效率（应该接近极致）要求很高的应用。

我们要实现一个核心的网络服务，最初考察使用 go 来完成，后来经过了一段时间的考察实验，甚至已经写了很多的 go 代码，发现完全满足不了我们需求（ GC、多线程切换损耗、内存消耗、调度器相关的等等相关的问题），最后还是决定选择使用 C 来实现。

而且在网络编程时又不想过度的使用 callback 去手写状态机，所以最好的方法就是实现一个“用 C 定制的 golang ”，去掉 golang 对高性能高并发应用场景不利的的东西，在 C 的极速与 golang 的易用之间找到一个最适合我们应用场景的平衡点，而 libaco 就是这个项目中的核心组件--协程库的实现，后续将会把全部的实现代码都放出来，敬请期待 :D

PS:

我也是 go 的爱好者，如果遇到要求不是这么高的场景，还是非常乐意选择 go 的。

@tommydong 当然如果是要做 tcp/udp 层的编程，还要解决好用户空间协议栈的问题 :D

@tommydong 之前研究过集群前端调度器很长时间，不过现在我没有在从事这方面的工作。

但是 libaco 是通用的，自然可以自由的与 dpdk 结合在一起，后续我还会放出来一个类 Golang 的 C 多线程网络库（前面给 pymumu 的回复中有具体的描述），只要修改一下底层 socket 的 API，应该就能直接的用在 dpdk 上面了。

@feverzsj 感谢你的提议，有机会一定尝试测试下 :D

@tt67wq 感谢支持哈 ;-)

@pymumu 感谢你的建议 :D

> c 的协程对编程的要求比较高，如果切换不合理，一不小心性能反而会下降，并且协程如果调用系统调用阻塞了，那整个任务也就挂住了。

是这样的，但是协程的使用目标一般都是借此实现类似 ngx lua cosocket 的这种编程模型的（用同步的语义书写异步程序，彻底摆脱所谓的 callback hell ），后面我还会继续放出来一个满足这个要求的库，可以认为是一个 C 语言实现的“ Golang ”定制版（砍掉 golang 中不适合高性能高并发低消耗场景的一些东西，尤其是复杂重量级的调度器和 GC 逻辑） :D

ngx lua cosocket: https://moonbingbing.gitbooks.io/openresty-best-practices/ngx_lua/whats_cosocket.html

> 并且现在多核的情况下，协程并不能有效利用 CPU

但是，为什么不能是多线程+协程（协程数 : 线程数 == C*T : T ）呢？

> 如果这个库能让 C 有类似的能力的话，就很好了。否则也只是特定的业务使用，并且还要小心使用。

是的，后面将会放出一个这样的库，完全满足你的设想 :D

（之所以打算两个分开放出来，是因为我认为协程库是很多场景中都有很大用处的一个组件，分开放出来应该对使用者们更有利，可以自由的定制选择）

@missdeer 后面也会加入对 ARM 的支持，以及对 Windows 操作系统的支持（ Microsoft ABI ），敬请关注 :D

@missdeer 编译器的话目前已知可以用的有 Gcc 和 Clang，正常情况下编译工具链只要包含 C 编译器和汇编器（还有链接器）应该都没有问题，当然具体的可以尝试一下哈。

@missdeer 目前支持所有 ABI 规范为 Sys V ABI Intel386 以及 AMD64 的操作系统，包括所有 Unix 系的操作系统，比如 Linux, BSD, MacOS, Minix, SunOS...等等。
具体只要查询一下目标系统的 ABI 规范是否为 Sys V ABI Intel386 或 AMD64 即可 ;-)

@pymumu 另外，10ns 在 3.5GHz 的 CPU 上大概只有 35 个时钟周期，这仅仅约为一个 32 位整型除法指令的耗时。


Intel Haswell:

instruction latency (core clock cycles)
add 1
mul 3
div r32 22-29
div r64 32-96

@pymumu

libaco 的上下文切换`acosw`耗时为 10ns (RHEL-7.5 & c5d.large on AWS)，而 ucontext 中有关于 sigprocmask 的系统调用（而且对于应用来说，在绝大多数情况下这个 Syscall 是没有存在必要的），时间数量级在 200-300ns 之间，而且系统调用会给当前运行线程带来严重的 cache-miss，会进一步影响线程的运行，所以，真正注重性能的网络应用是不会选择使用 ucontext （还有一点，ucontext 中的 setcontext 等等函数已经从 POSIX 标准中移除）。

PS:

$ man 3 setcontext
...
CONFORMING TO
SUSv2, POSIX.1-2001. POSIX.1-2008 removes the specification of getcontext(), citing portability issues, and recommending that applications be rewritten to use POSIX threads instead.
...

另外，OpenBSD 中并没有实现 ucontext。

@jedihy @est 十分感谢 :D 希望这个项目能够对朋友们有些用处 ;-)

@lsmgeb89 感谢 :D 我也非常喜欢数学证明，写的时候也非常地开心。

@tommydong 早上好，实在不好意思哈，昨天回复完上一位朋友的留言后就去睡觉了 ;-)

> 1000 万的协程并发的应用场景？

一个简短的总结就是，高性能、高并发和对内存使用效率要求很高的场景（当然，对这三点要求低些的应用肯定都是能用的，哈哈）。

一个最典型的案例就是网络服务程序，比如大型集群的前端调度器（单机并发数百万数量级，比如像以用户空间 dpdk 实现的 Director ），以及像 Nginx、Redis 这样的对以上三点要求很高的网络服务基础设施。

穿插一些相关的：

Golang 也很棒，但是却不太适合上面的场景，与 C/C++相比，Golang 的编译器的优化有较大的提升空间（且 GCC 已经有 30 多年的演进历史），语言的抽象层过于重量级（ Golang 的核心开发小组为了用户的易于使用已经牺牲了太多的性能，在多线程高并发的场景下，调度器损耗太大，当然还有 GC 问题...）。

我其实也是 Golang 的长期用户和爱好者，如果碰到对这些指标要求不是很高的服务程序我还是会很乐意选择 Golang 的 ;-)

实在抱歉，纠正：

链接： https://github.com/Tencent/libco/issues/90

> 比如腾讯的 libco 中就有一个 bug，在微信的生产系统中隐藏了五年多都没有被发现（从它的 Github 代码仓库中看是如此），就是因为在实现的时候没有严格遵守 Sys V ABI 的规范导致的。

@icylord 感谢 :D

协程的根本思想应该是比较清晰的。

但如果要具体地去实现一个协程库，需要对系统的 ABI 规范很熟悉（重点是二进制函数调用中寄存器与栈的一些约定细节），也需要些汇编（重点是函数调用约定部分）的基础知识（这部分其实比较简单，如果对计算机体系结构比较熟悉的话初学它可能一两个小时就学会了）。

比如腾讯的 libco 中就有一个[bug]( https://github.com/Tencent/libco/issues/90)，在微信的生产系统中隐藏了五年多都没有被发现（从它的 Github 代码仓库中看是如此），就是因为在实现的时候没有严格遵守 Sys V ABI 的规范导致的。

libaco 项目中的文档还是比较齐全的，而且还有严格的数学证明，希望对你有所助益哈 ;-)

当然，如果有问题的话，可以发 Issue 大家一起探讨，这样会更加有乐趣 :D

@Kilerd 十分感谢哈 ;-)
协程的实现以及应用确实非常有趣，希望这个项目的代码以及文档能够对你有用处，如果遇到任何问题可以发 Issue 大家一起讨论 😁