saipubw

> > 初步想法是： > > > > 1. async-simple提供一个正式的callback_awaitor，用于普通用户封装cb，并且能够正确处理cb立即执行问题。 > > 我倾向不添加 callback awaiter。在等待什么结束后执行这本就是 co_await Lazy 的语义。 > > > 2. 后续需要提交几个pr，处理mutex的爆栈问题。 > > 之前提到过，应该让这几个组件通过 executor 进行调度而非直接 resume 但没有调度器的情况下，mutex还是会有问题。我的想法是，可能要看看如何避免mutex::unlock重入时立即resume协程，而是延迟到上层的unlock来resume协程。

> > 初步想法是： > > > > 1. async-simple提供一个正式的callback_awaitor，用于普通用户封装cb，并且能够正确处理cb立即执行问题。 > > 我倾向不添加 callback awaiter。在等待什么结束后执行这本就是 co_await Lazy 的语义。 > > > 2. 后续需要提交几个pr，处理mutex的爆栈问题。 > > 之前提到过，应该让这几个组件通过 executor 进行调度而非直接 resume 但是用户需要一个能够suspend/resume协程的工具。其实目前已经有了，就是async_simple::future/promise。 这个组件即使不添加调度器，也不会因为在suspend中resume而爆栈，因为future...

> > > 首先吧，我认为如果真的不希望用户调用底层的接口，应该在设计上就杜绝这种可能，也就不能暴露协程handle给用户，比如像asio的协程支持，就是用户层无法访问协程handle。 > > > 既然用户能访问，而且示例中也有这类的用法，也属于十分正常的用法，那么解决这个问题是非常有必要的，这也是库的健壮性问题。 > > > 当然这是我的建议，如果你并不认同，不打算处理，这是你的代码，决定权在你。 > > > 谢谢。 > > > > > > > > 1. 示例中这样用，主要是任务一定会交给asio调度，不存在立即执行，因此只看demo本身，是不存在爆栈问题的。 > > 2. 我个人的想法是，如果打算提供一个通用的`AwaiterCallback`机制，方便不熟悉协程的用户进行封装，那确实需要处理立即执行的情况。...

> > > > 初步想法是： > > > > > > > > 1. async-simple提供一个正式的callback_awaitor，用于普通用户封装cb，并且能够正确处理cb立即执行问题。 > > > > > > > > > 我倾向不添加 callback awaiter。在等待什么结束后执行这本就是 co_await Lazy 的语义。...