我不知道啊。。怎么会有那么多玄学呢？按说协程是很简单的东东。在 20 年前的 python 和 golang 里面都是基本的语言结构了。新的 c++20 只提供了最基本的 stackless coroutine 语法，想要实现 python, golang 的协程还要加上一个标准库才显得复杂吧。

我说的这种 mmap() 一般是 c++ stackful coroutine 的实现方式，很凑巧地刚好匹配 c++ 资源管理。python 倒是不需要，而且也做不了资源管理。

【 在 ziqin 的大作中提到: 】
: 如果是真的这么轻量级，前面这么多关于协程stack的玄学部分又怎么解释。。。
: 事。
--
FROM 110.81.0.*

太有用了啊。比如 python 的 os.walk() 就是典型的应用。用迭代器以后，不再需要把整个 list/map 传递给上层调用者，经常能够省掉大量内存。

再来一个编译原理的应用，解析 token:

https://github.com/hgoldfish/gsion_script/blob/master/gsion#L78

顺便说一下，这个也是协程 coroutine 哦。很多人把 coroutine 和 fiber, green thread 等价，但其实 coroutine 是更宽泛的概念。

【 在 ylh0315 的大作中提到: 】
: 确实不知道这玩意儿有啥用。
--
修改:hgoldfish FROM 47.243.39.*
FROM 47.243.39.*

我的朴素理解：

协程就是内嵌数据、自带可更新的状态、可根据当前状态和数据恢复/继续执行的一个东西

至于是用栈，还是用另外的某种数据结构（比如一个很另类的类）来实现这个东西，理论上都是可以的

关于协程的恢复执行，可能是相对底层一点的协程调度程序基于IO触发的，也可能是用户手动触发的比如你可以手动的让一个协程恢复/继续执行。前者的典型表现是go读写socket，后者典型的表现就是Python的generator。其实本质上，协程的恢复执行或者调度都是人工的，只不过这个人工可能是掌管真正的IO的协程调度程序，也可能真的是你的应用程序

但是协程似乎并不能很优雅的处理这样一个问题：同时发N个消息出去，然后等待它们的响应，等所有的响应都到之后，再做下一个动作。用协程似乎还是会沦落到要写一个switch来处理响应

【 在 hgoldfish 的大作中提到: 】
: 太有用了啊。比如 python 的 os.walk() 就是典型的应用。用迭代器以后，不再需要把整个 list/map 传递给上层调用者，经常能够省掉大量内存。
: 再来一个编译原理的应用，解析 token:
: https://github.com/hgoldfish/gsion_script/blob/master/gsion#L78
: ...................
--
FROM 113.120.108.*

最后一段。
一个协程发一个消息出去，然后等结果就好了。
都是自动处理的。
SendNet();
RecvNet();//里边可能会yield，你不需要管，你也不知道你自己是否是一个协程。只是被告诫，可能是个协程，不要把线程锁跨越之，回来后很可能不是原来的线程了。
够优雅否？
【 在 wallyz 的大作中提到: 】
: 我的朴素理解：
: 协程就是内嵌数据、自带可更新的状态、可根据当前状态和数据恢复/继续执行的一个东西
: 至于是用栈，还是用另外的某种数据结构（比如一个很另类的类）来实现这个东西，理论上都是可以的
: ...................
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*

提醒一下，五个响应回来的顺序不一定

【 在 ylh0315 的大作中提到: 】
: 最后一段。
: 一个协程发一个消息出去，然后等结果就好了。
: 都是自动处理的。
: ...................
--
FROM 113.120.108.*