microcai
microcai
> executing a function before resuming a coroutine is done via ontop_fcontext() - wouldn't this satisfy your needs? didn't know ontop_fcontext ;) it suits my needs ! thanks a lot.
> executing a function before resuming a coroutine is done via ontop_fcontext() - wouldn't this satisfy your needs? the API satisfy my needs. but when I look into the implementation,...
其实这个问题解决起来并不困难。也不是属于什么解决了这个问题就破坏了其他代码的问题。 无非就是解决这个问题没有 KPI ，还会暴露自己。这在月饼公司可是非常危险的。 你应该私下联系作者反馈。在这种公开的 地方发 issue 会被人记恨啊 。 阿里可是一家 KPI 导向，HR 有生杀大权的公司。
> async_simple本身的设计有这个问题么？我看了下好像只有demo的这个例子是这样的。 是 微软的锅。提交的第一个版本是带 bug 的。而 async_simple 是按第一个版本设计的。要修正需要按微软提交的第三个版本设计。略有改动。编译器为了不破坏兼容性，是把 bug 版本也兼容了的。
> > > async_simple本身的设计有这个问题么？我看了下好像只有demo的这个例子是这样的。 > > > > > > 是 微软的锅。提交的第一个版本是带 bug 的。而 async_simple 是按第一个版本设计的。要修正需要按微软提交的第三个版本设计。略有改动。编译器为了不破坏兼容性，是把 bug 版本也兼容了的。 > > 这里的第 N 个版本指什么？ jackarain 发的评论区里有引用一篇 微软的人写的解释来龙去脉的文章。
首先，await_suspend 返回 void 严格来说是不标准的。因为那是属于微软提交的第一版。是收录在 c++20 : ts 里的。而不是正式标准里。 返回 std::noop_coroutine 的是微软在正式标准前打上的补丁。这个才属于正式标准。 只不过为了向后兼任而没有废弃掉 void 返回值的版本。
> > > > 首先吧，我认为如果真的不希望用户调用底层的接口，应该在设计上就杜绝这种可能，也就不能暴露协程handle给用户，比如像asio的协程支持，就是用户层无法访问协程handle。 > > > > 既然用户能访问，而且示例中也有这类的用法，也属于十分正常的用法，那么解决这个问题是非常有必要的，这也是库的健壮性问题。 > > > > 当然这是我的建议，如果你并不认同，不打算处理，这是你的代码，决定权在你。 > > > > 谢谢。 > > > > > > > > > >...
是这样的。他这个是协程的 mutex ， 用在协程上的。 然后协程代价比较低。 所以开的协程比较多。比如说有十万个协程跑在那个 mutex 保护的地方。 然后，有十万个协程都在 co_await mutex.lock(); 那么，有一个协程 执行 mutex.unlock(), 则必然就会有一个协程被 resume. 然后他 resume 的地方，执行完关键代码，就必然会调用 unlock .... 然后调用栈就变成了 unlock resume ... unlock resume ... unlock resume...
> > 肯定可以的。但暂无此计划，嵌入式编译器支持20 coroutine的不多。 > > 我个人感觉这个库的 C with Macro 是真的看不懂，如果能给一点框架的基本原理的话我可以试着用20重写，也是完全独立于std的 PlatformIO + c++20 绝对会打开你新世界的大门。 参考这个演示仓库 [https://github.com/microcai/mcu_coro_demo](https://github.com/microcai/mcu_coro_demo) 。演示 c++20 协程实现的超迷你 RTOS。
> > > > 肯定可以的。但暂无此计划，嵌入式编译器支持20 coroutine的不多。 > > > > > > > > > 我个人感觉这个库的 C with Macro 是真的看不懂，如果能给一点框架的基本原理的话我可以试着用20重写，也是完全独立于std的 > > > > > > PlatformIO + c++20 绝对会打开你新世界的大门。...