148楼结合149楼一起看，解释清楚了协程在事件循环中的作用。
对楼主说一句，在148楼的事件循环里，如果应用插件没有IO需求，已经是完美的，实现了对CPU资源的最充分的运用，真的没有协程需求。如果有IO，并且有长时间的等待，就有了协程需求。见149楼。
【 在 hgoldfish 的大作中提到: 】
: 事件循环跟协程是两回事啊。
: 事件循环只是协程的一种用途。
: 理论上可以不使用事件循环实现协程的。
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*

嗯。我比较想讨论的是，你这个 "task" 概念不够清晰明了，还是 "coroutine" 这个词比较适合描述你的想法。

而用户线程，最好用巨硬以前发明的纤程 (fiber) 来指代。这样子:

coroutine <-impl->  process
                    thread
                    fiber

协程可以使用三种方式来实现。不论是 c# 还是 c++ 标准库都认为 coroutine != fiber.

thread+fiber 的混合实现经常被称为 green thread.

然后呢，fiber 的实现方式有两种 stackful 和 stackless.

你做的协程框架其实是 stackful green thread. java/go 的实现则是 stackless green thread.

coroutine 的应用方式也有多种，协程池、generator 和 io 事件循环都是协程的应用场景。

事件循环还有多种实现方式。。

【 在 ylh1969 的大作中提到: 】
: 另外，纵观我的发言，都是站在框架的角度，不涉及任何具体应用，所有应用都抽像成task。只讨论task的调度问题，进程，线程，协程都是调度工具。讨论什么调度方法能够充分利用系统资源。
: 至于框架与应用的结合，见本版，服务器动态模块热插拔管理，把应用写成动态模块，https://www.newsmth.net/nForum/#!article/CPlusPlus/431596
: 加入指定目录，写个客户端，指名调用就可以了。至于执行器，是进程，线程，协程，基本不需要关心。
: ...................
--
修改:hgoldfish FROM 47.243.39.*
FROM 47.243.39.*

这个实现不流行，属于 stackful fiber 的实现方式，但是奇葩的是，这个调用会陷入内核。所以其实没啥人用这个调用。

【 在 ylh1969 的大作中提到: 】
: task就是一个总context。里边有好多子context。
: 从线程池改造成协程时，添加一个ucontext，
: 然后就是4个函数：
: ...................
--
FROM 110.84.123.*

原理是这样没错。但 linux 实现的 swapcontext() 比较奇葩，会陷入内核。所以这几个 posix 函数没人用。

【 在 ylh1969 的大作中提到: 】
: 跟内核毫无关系。
: get就是拷贝寄存器保存现场
: set就是恢复现场
: ...................
--
FROM 110.84.123.*

linux 的实现比较奇葩一些。有个 signal 的处理进了内核。

github dotcom/bminor/glibc/blob/master/sysdeps/unix/sysv/linux/x86_64/swapcontext.S#L74

【 在 ylh1969 的大作中提到: 】
: 源码我见了，不进内核。
--
FROM 110.84.123.*