08｜Coroutines：“零”开销降低异步编程复杂度

作者回复: 感谢你！ using promise_type = promise<T> 是给primise<T>起了一个别名，这个别名是promise_type 等同于C++98中的 typedef promise<T> promise_type

作者回复: Modules其实是只有在所有的新代码都采用Modules后才能深刻感受的，但是C++需要引入非Modules代码，肯定就会使得问题反而复杂化了。 Coroutine中，C++标准只提供了“协议”，具体的实现需要我们根据自己的需要来做。但是如果在封装好一个完善的框架后是可以大幅度降低异步编程的复杂性的——就像我们可以在C++22 Coroutine的基础上实现一个完善的类似于libuv之类的异步I/O框架，应用开发者在框架的基础上开发应用就能降低复杂度了，而框架的开发者也能有足够的灵活性和自由性。因此我们需要从一个使用者的角度来看Coroutine，而不是框架底层的开发者，这样就不会觉得Coroutine会提升复杂性了。

作者回复: co_yield就是在暂停协程，并将值“return”回调用者。

作者回复: 生成器在执行代码的时候，调用生成器的代码必然需要暂停等待被调用者返回结果。 但这里是同步还是异步是需要看你如何管理调用者和被调用者的执行。 比如，如果像我们这种简单的生成器，肯定就是同步的，但如果现在调用者和被调用者是在两个线程上，并且两者都是可被调度的任务，当调用者等待生成器时就可以通过调度将本线程的CPU让给其他需要CPU的任务，如果能有这种调度框架，那么从整体上来说就是异步的，因为这种情况主线程基本时不会阻塞的，永远会通过调度器分配任务，不会浪费等待生成器返回结果时的CPU时间。因此同步/异步模型还是需要从不同角度和不同的实现方式来看。协程为我们封装这种能力，实现相关的框架提供了一个技术上的基础。

作者回复: 标准库对coroutine的支持预计还需要等待后续的标准（C++26或之后）。但是在这之前，C++已经从核心语言特性层面，支持了协程，如果要在工程中使用协程实现非嵌入式的高性能异步计算能力，已经是可能的了。 不过，就像正文所说的，目前这些接口约定还需要开发者实现。我在课程的配套代码中实现了协程的接口约定，可以参考其实现基于协程的高性能异步。 或者，等待 std::lazy 落地。

作者回复: C++选用了无栈协程主要是由以下考量： 1. 无栈协程具备更好的伸缩性和扩展性，相当于把对协程的高层接口语义定义的权力全部交给了开发者，因此可以允许开发者设计开发协程库，甚至基于无栈协程构建类似于有栈协程的高层接口。而C++26可能也会加入lazy，提供类似于有栈协程的封装，降低对原有代码的侵入性。 2. 与已有的其他基础设施，比如线程等完全正交设计，可以无缝集成。 3. 因为可以自定义挂起和恢复的实现，因此相比有栈协程可以更加高效。 4. 在有些团队或者公司可能因为各种原因会禁用异常，这种情况下自定义的无栈协程会有更好的性能。 总之，就是在日后的标准（比如C++26）中加入便于初学者使用的类似于有栈协程的接口，又允许专家开发者根据自己的需求去根据实际问题场景做深度的定制封装，这就是C++标准的一个设计原则。如果直接用了有栈协程，那就基本封死了开发者扩展定制的可能性，不符合C++的基本设计理念。

作者回复: Q1：局部变量的生命周期可以理解成这个变量在堆栈上的存在时间，超出生命周期时这个局部变量就会被销毁，如果是对象就会调用析构函数。 Q2：exposition only是为了解释编译器所提供的标准库实现可能是如何实现coroutine_handle的。coroutine_handle是C++标准库提供的标准类型，这个类型不需要coder自己实现，但是C++标准只定义了coroutine_handle的public部分的接口，内部如何实现完全由编译器包含的标准库具体实现决定，这就是为什么“编译器可以根据自己的需求定义这里的实现”。 Q3：协程完全可以用于长耗时运算，但是如果这样我们会利用线程或者进程通信、网络通信等机制将计算释放给其他的计算单元计算，这样当前线程还可以继续其他计算任务。协程只是提供了计算任务的手动控制切换的能力，和其他的并行并发计算技术是完全正交的。