microcai

允许 co_create 使用任意多参数的入口函数。

2

允许 co_create 使用任意多参数的入口函数。 可以大大简化代码使用。 不需要总是对 void* 强转来强转去。十分的丑陋。

add an ability to execute a callback function on behalf of target coroutine stack right before return to target coroutine

3

# rational when do "jump_fcontext", we have an opportunity to pass "void*" to target coroutine. how to do with that argument is up to the target coroutine. some time we...

大硕的库能够启发出协程？大硕那个库没法搞协程。受大硕的库启发，简直牛头不对马嘴。他那个库一点都不能启发什么东西。只会教坏人的思想。走到异步的对立面。学了大硕思想，proactor 都给你折腾回 reactor

stack-like coroutine frame memory allocation

2

when coro foo calls (or, precisely speeaking, awaits) bar, and bar awaits bob, the coro frame is allocated in foo, bar, bob order, and when their job done, the deallocating...

作者在代码里写了这么一个 FIXME ```c++ Task write(const Buffer& buf) { auto& loop = get_event_loop(); ssize_t total_write = 0; while (total_write < buf.size()) { // FIXME: how to handle write event? // co_await...

网络库常见的糟糕设计有哪些

1

原文见 https://www.jackarain.org/2024/06/07/network-library-design.html 今天来批判一下 c++ 网络库常见的糟糕设计, 因为很多库作者往往是学而不思, 对于网络库的设计不得要领, 这种现象由其是在国内以 muduo 为代表的糟糕设计的模仿者众多, 废话不多说, 直接进入主题. 网络库不应该 copy 用户要发送的数据. 第一, 复制用户数据点, 它会增加内存消耗和 CPU 负担, 影响性能. 第二, 它会导致网络库的内存使用量控制是个麻烦, 在发送频繁的程序中, 可能导致内存不受控制(或者控制十分麻烦)的增长, 这时用户体验会非常糟糕, copy 用户数据这种设计是将库的使用假定在用户不会频繁发送数据的前提下, 可以无脑调用发送, 这本质上是给于用户错误的网络编程的机会....

为何不使用 asio 的协程封装库

1

既然是基于 asio 做的，为啥又要依赖 阿里的 async_simple 呢？ asio 自己就有协程支持吧。 就算有个中缘由不想用 asio 的协程，那 boost.cobalt 也提供了不错的协程封装。 更重要的是，既然用了 asio ，如果没有计划支持 HTTP3 的话，为何不直接使用同样基于 asio 的 beast 呢？

add cmake build system support move public header to include/ so that people can intergrate nanovg by adding two lines to their cmake: add_subdirectory(nanovg) link_libraries(nanovg)