saipubw

I try to test pipeline performance, and if small buffers count > 16, performance drop seriously. At least we should mention it in document.

The document said: > When awaited using &&, the co_await expression waits until both operations have completed successfully. As a "short-circuit" evaluation, if one operation fails with an exception, the...

Interesting. In vulkan render mode, once Homura appears in the lens, the sight will be blocked and cannot play normally. 

命令"Zhihu: Search Items"导致错误 (403 - "{\n \"error\": {\n \"code\": 10002,\n \"message\": \"10002:\\u8bf7\\u6c42\\u53c2\\u6570\\u5f02\\u5e38\\uff0c\\u8bf7\\u5347\\u7ea7\\u5ba2\\u6237\\u7aef\\u540e\\u91cd\\u8bd5\"\n }\n}\n") message的unicode转换结果：求参数异常，请升级客户端后重试 估计是知乎的前端接口改了

> 这里是有些问题，unlock 时可能在当前线程 resume 太多任务导致卡死。之前也有个 FIXME 说 Mutex 应该实现 Executor 假设十万个协程同时抢一个mutex，那么就会不断递归遍历Mutex的coroutine handle链表，很可能导致栈溢出。之前在CI上偶发的见过这个问题。

> 其实我想做的就是，在执行多个RescheduleLazy时其中一个执行异常了，需要通知所有关联Lazy主动退出，并且等待所有Lazy执行完毕，再进行下一步操作。 不知道有没有好的方法。 典型的取消操作

> > 其实我想做的就是，在执行多个RescheduleLazy时其中一个执行异常了，需要通知所有关联Lazy主动退出，并且等待所有Lazy执行完毕，再进行下一步操作。 不知道有没有好的方法。 > > 典型的取消操作 #402 给出了初步设计方案。 通过执行 ```cpp co_await collectAll(work1(),work2()); ``` 第一个返回的任务会触发取消信号。尝试取消尚未完成的任务。 取消是协作式的，需要异步IO对象/调度器支持取消操作，或者手动检查。 async_simple所有自带的组件会在将来支持取消操作，并抛出std::system_error{std::errc::operation_canceled}异常。 实现一个支持取消的sleep的简单例子： ```cpp Lazy sleep_1s() { CancellationSlot* slot = co_await currentCancellationSlot{}; auto p =...

已合入主线。 See [doc](https://alibaba.github.io/async_simple/docs.cn/%E4%BF%A1%E5%8F%B7%E4%B8%8E%E4%BB%BB%E5%8A%A1%E7%9A%84%E5%8F%96%E6%B6%88.html#collect%E5%87%BD%E6%95%B0%E4%B8%8E%E7%BB%93%E6%9E%84%E5%8C%96%E5%B9%B6%E5%8F%91)

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

初步想法是： 1. async-simple提供一个正式的callback_awaitor，用于普通用户封装cb，并且能够正确处理cb立即执行问题。 2. 后续需要提交几个pr，处理mutex的爆栈问题。