最近抽空继续对 libcopp 进行了更新和小幅优化。 首先的Merge了 boost.context 1.70.0 。
libcopp更新 (merge boost 1.59 context) 之前由于兴趣写了一个协程框架，目前这个框架已经投入项目中使用。...这个框架的上下文部分是使用了boost.context，但是从开始写libcopp到现在，boost.context也更新了几个版本。...看了下定位基本就是和我的libcopp里的copp部分（也就是不包括cotask）一样。...所以在这些平台中，boost.context的execute_context会不可用，而libcopp只是不能多线程运行。...变更列表 libcopp的近期的变动如下： 1. 跟进上下文初始化和切换的汇编代码更新 2. 跟进增加了pe下的gnu as支持的上下文汇编支持（但是貌似不太正常） 3.
然后来Merge了一下 boost.context 最新 1.69.0 版本的asm部分到 libcopp。...但是我在 libcopp 里仅使用了它上下文切换的部分和栈与上下文结构，没有使用它的协程对象的部分（主要是觉得它的实现不好用，而且有一些历史遗留包袱）。所以这个对 libcopp 来说相当于没有变化。...不过有一项是和 libcopp 有一些关系的，那就是为ELF的ABI添加了 .file 段。...原来 libcopp 的所有的地址都是对齐到 max_align_t 的。
前段时间有同事联系我想看看可能推广我之前写的协程库 libcopp，虽然 libcopp 已经用到过好几个项目上，这几年也断断续续地写了一些实现细节的文章，但是也但确实需要系统、概览性地介绍下 libcopp...Github: https://github.com/owt5008137/libcopp Document: https://libcopp.atframe.work/ libcopp 的由来 协程的概念并不是什么非常新颖的东西...于是 libcopp 就诞生了。 设计目标 我设计 libcopp 的时候优先还是考虑到我涉及的业务类型（游戏服务器）的。...但是 libcopp 在应用中还是使用的对称式 ，而且对称式理解和管理起来更方便，所以 libcopp 还是还原了对称式的做法。...现在已经可以通过 vcpkg 的 vcpkg install libcopp 来安装 libcopp。
无奈之前和call_in_stack的作者聊了一阵，发现了一些libcopp的改进空间。然后顺便看了新的boost.context的cc部分的代码，有所启发。...goroutine压力测试 这里还是用了和libcopp里差不多的测试方法。...那么为了对比，还需要同样在这台机器下，同样环境的libcopp的测试结果。 这里用的是go语言推荐的协程间共享数据的方式，应该是最贴近libcopp的流程了。...而且go语言本来还就是目标于高性能分布式系统的，并且很多这种分布式系统的一些逻辑可能并不特别重，都能容忍这个开销，何况libcopp呢。...现在还是放在https://github.com/owt5008137/libcopp的v2分支里。 当然哪位大神有更好的建议希望能够不吝赐教。
在之前，我写过一个初版的C++20协程接入 《libcopp接入C++20 Coroutine和一些过渡期的设计》 。...我们整个服务器框架的和协程相关的改造分为两部分，第一部分是 libcopp 这个库的底层支持，另一个就是现有业务流程的改造过程。...我先完成了 libcopp 对C++20协程适配支持，这也是本篇分享的主要内容。...显然我们 libcopp 一个非常重要的要求就是抹平这些差异。...在 libcopp 的 task_future 中就有类似问题。
这当然也和 libcopp 的尽量防止被误用和误用情况下尽可能保证安全的设计原则有关。...+动态栈池 32 ns 96 ns 77 ns 212 ns 213 ns libcopp+libcotask+动态栈池 49 ns 134 ns 134 ns 256 ns 371 ns libcopp...上面还提供了使用 libcopp 传统有栈协程的开销对比。...但是切换开销目前 libcopp 的切换开销比裸调用原始API大，主要原因有两个。.../task.h> #if defined(LIBCOPP_MACRO_ENABLE_STD_COROUTINE) && LIBCOPP_MACRO_ENABLE_STD_COROUTINE typedef
libcopp v2内存布局 开发libcopp v2版本的最大目的是优化allocator的接口和内存碎片。 原来的allocator虽然是可定制的，但是是内置的。...60 ns 3.7 us 91 ns 3.5 us 239 ns libcopp+动态栈池 60 ns 109 ns 90 ns 261 ns 238 ns libcopp+libcotask 79...+libcotask比单纯的libcopp多了进程内唯一ID的分配、状态转换和维护、可调用对象和跳转函数直接的转换和事件响应，并且保证了线程安全。...工程上一般会用libcotask，但是功能上libcopp才是和其他对比项类似的部分。在压力测试中，也没有包含libco和libgo里系统函数hook的部分。...libcopp/libcotask测试代码：https://github.com/owent/libcopp/tree/v2/sample goroutine 测试代码: https://gist.github.com
本来我并没有给libcopp里的功能加锁的打算，因为上层dispatcher还是比较容易做到安全分发的，所以原来并不保证线程安全。而且线程安全这种问题单元测试比较难写，可能还得碰点运气。...有一个重要的变化（虽然libcopp里并没有用到），废弃了execution_context。...所以libcopp仍然使用智能指针维护协程上下文。 性能优化 一开始看到libgo的时候，发现它比libcopp快一些。但是因为底层都是boost.context，所以按理来说不会有太大差别。...起初测试的时候用的是-O2，后来发现libcopp使用-O3编译的效果，性能就和libgo（因为libgo的CI里配置的是使用-O3）接近了。即便是这样，我后来还是发现libcopp能有一些优化空间。...这个优化之后，libcopp的-O2也能有libgo的-O3相近的性能了。
之前测出来libcopp还有一些列优化点，但是要破坏之前的API，所以整理了一下优化的想法和方案。 预留空间和合并分配 之前有太多的堆内存分配了，导致很多碎片。...减少原子操作 之前写libcopp merge boost 1.64和相关优化的blog里有提到这一点。主要是原子操作会导致cache miss。...所以libcopp的优化暂时搁置吧，不过以后会主要以v2版本的api为准，基本不会再变更接口了吧。
架构下需要额外作一些适配 Boost.Test的话，按Boost的尿性，一旦引入就会涉及上千个文件 目前这个单元测试框架还没有抽离出来，所以代码暂时放在 https://github.com/owt5008137/libcopp.../tree/master/test 还有个镜像地址: http://git.oschina.net/owent/libcopp 后面的链接基本也有一样的镜像地址 这里面除了case目录是用于libcopp...（详见: https://github.com/owt5008137/libcopp/tree/master/test/frame/test_macros.h 和 https://github.com/...owt5008137/libcopp/tree/master/test/app/main.cpp ） 一键切换适配方案 – Boost.Test boost这个比较麻烦，因为boost的接口方式不一样，.../test/frame/test_manager.cpp ） 还是宏定义的部分变更（详见: https://github.com/owt5008137/libcopp/tree/master/test
架构下需要额外作一些适配 Boost.Test的话，按Boost的尿性，一旦引入就会涉及上千个文件 目前这个单元测试框架还没有抽离出来，所以代码暂时放在 https://github.com/owent/libcopp.../tree/master/test 还有个镜像地址: http://git.oschina.net/owent/libcopp 后面的链接基本也有一样的镜像地址 这里面除了case目录是用于libcopp...（详见: https://github.com/owent/libcopp/tree/master/test/frame/test_macros.h 和 https://github.com/owent...简单地说就是分支比较多 在入口处要判断是静态库还是动态库，有没有使用boost.test内置的函数（详见: https://github.com/owent/libcopp/tree/master/test...） 还是宏定义的部分变更（详见: https://github.com/owent/libcopp/tree/master/test/frame/test_macros.h ） 剩下的就是一些环境判断和控制开关的宏了
libcopp v2内存布局 开发libcopp v2版本的最大目的是优化allocator的接口和内存碎片。 原来的allocator虽然是可定制的，但是是内置的。...60 ns 3.7 us 91 ns 3.5 us 239 ns libcopp+动态栈池 60 ns 109 ns 90 ns 261 ns 238 ns libcopp+libcotask 79...+libcotask比单纯的libcopp多了进程内唯一ID的分配、状态转换和维护、可调用对象和跳转函数直接的转换和事件响应，并且保证了线程安全。...工程上一般会用libcotask，但是功能上libcopp才是和其他对比项类似的部分。在压力测试中，也没有包含libco和libgo里系统函数hook的部分。...libcopp/libcotask测试代码：https://github.com/owt5008137/libcopp/tree/v2/sample goroutine 测试代码: https://gist.github.com
前言 之前写了 《协程框架(libcopp)v2优化、自适应栈池和同类库的Benchmark对比》 和 《C++20 Coroutine》 ，但是一直没写 C++20 Coroutine 的测试报告。...压力测试机环境 为了方便比较，我更新了一下之前在 《协程框架(libcopp)v2优化、自适应栈池和同类库的Benchmark对比》 里的测试项目的版本。...而 libcopp 在实际应用中是搭配上了线程安全检查和一些防止误用的状态检查的，全是atomic操作，甚至 libgo 那种加锁的线程安全的检查，性能会会受到一定影响。...这是 《C++20 Coroutine》 比不上 libcopp 的地方。 这也是我前段时间思考给 libcopp 接入 《C++20 Coroutine》 做Context管理的最大困难。...34 ns 4.1 us 80 ns 3.8 us 223 ns libcopp+动态栈池 32 ns 96 ns 77 ns 212 ns 213 ns libcopp+libcotask 50 ns
前言 之前写了个C++的协程框架libcopp，底层使用的是boost.context实现，然后剥离了对boost的依赖。然而这样意味着我必须时常跟进boost.context的更新。...这些变化使得libcopp的逻辑关系也必须有一些相应的调整，为了理清思路，这些都在后面分析。...因为首先libcopp本身处理了它完成的功能，虽然它用模板写得，但是本身有一些兼容性问题。...内部使用了侵入式智能指针，反正libcopp本身能够很容易实现这个，并且benchmark里本身就有使用预定内存池的例子，所以我认为这是非关键的功能。...libcopp的修订 这次的merge，使用新的设计模型是必然的，但与此同时，我也会做一些细节的优化和调整。
虽然之前陆陆续续抽时间改造一些组件，让它支持C++20协程，期间也记录了一些早期的设计思路和踩的坑（包括 《libcopp接入C++20 Coroutine和一些过渡期的设计》和《libcopp对C++...（《libcopp对C++20协程的接入和接口设计》 里已经提过的踩坑点和编译器BUG这里不再复述。）...C++20协程的一些背景 之前在 《libcopp对C++20协程的接入和接口设计》 里已经做了一些文本上的设计和总结记录了，这里为了方便直观点，再提取一些重点吧。 首先C++20协程的原理是啥呢？...所有协程接口必须 co_await 由于我们的协程库（libcopp） 在父协程函数调用子协程函数没有调用 co_await 的话，子协程在析构时会进入 cancle 状态。...写在最后 我们的框架方案和底层协程库都是开源的，协程库（libcopp）开源地址在 https://github.com/owent/libcopp 。
按照我自己风格还是喜欢C++，所以协程库定名为 libcopp 。...源码托管在 github: https://github.com/owt5008137/libcopp 镜像托管 http://git.oschina.net/owent/distinctionpp...libcopp 接下来是我们的libcopp的设计思路。
另外，框架中优先也会提供C++的协程模式的RPC行为，这涉及我写得另一个库libcopp。...另外，由于我们的现有的服务器框架使用了libcopp，近期测试期间花了几分钟随手做了一个响应时间的统计，可以用来查看是否有响应过长需要优化的协议接口。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
