c++20 里面会把 co_yield 转换成真正的调度代码啊。

转换成 c/asm 代码，co_yield 就是个 return 语句。也就是返回它的调用者。

而调用者用 co_await 切换到 generator 刚才退出的位置继续执行。

这就是最简单的纤程调度了啊。只有两个纤程，相互跳来跳去。

有了这个最简单的模型，再推广到更广泛的应用领域去。比如 c++20 的协程没说不能多线程。

【 在 ylh1969 的大作中提到: 】
: 还是没有解决异步IO的问题。
: 思考了一下，在C++协程里，co_yield没有出现context，不知道yield跑哪去了。
: 所以没办法调度。
: ...................
--
FROM 117.28.163.*

对啊。协程有时候和线程相比就是模糊不清的。

一个线程，在内核空间时碰到 IO 就主动 yield 的纤程，在用户空间时又是因为陷入内核态被调度器切换走的线程。

我们完全可以把 syscall 这条指令看成是纤程的 co_yield

这就是为啥我越来越觉得协程 coroutine 应该作为一种高层抽象，而不是具体的底层实现技术。具体的底层实现技术我觉得巨硬之前取的名字挺好的，就叫做 fiber，指代在一个线程里面切换的协程。

你实现的协程，是一种在多个线程之间切换的协程，应该叫做绿线程 green thread. 现在 java 改做 virtual thread 了。

【 在 ylh1969 的大作中提到: 】
: 内核调度，就是线程/进程呀，你说的所有异步过程发生在内核，在IO时，肯定会锁死线程/进程，但是别的线程/进程不受影响，在用户态，看起来就是同步IO。
: 在所有的例子里，协程就是语法糖，就如你说的，性能另说，它不是关键的，必不可少的技术方法。
: 如果把协程的context封装了，那跟线程又有什么区别呢？你的那些例子用多线程干可能更好。
: ...................
--
修改:hgoldfish FROM 117.28.163.*
FROM 117.28.163.*