现在协程流行的原因，还是线程的成本太高。

一个是现在的cpu每个核心有独立缓存，一个线程固定分配到一个核心是最好的，如果线程反复随机调度到不同核心，就会导致缓存的效率大幅下降，

另一个是操作系统层面，线程是一个比较重的对象，操作系统支持的线程数量上限也不高。

所以要用线程取代协程做并发，还是需要cpu结构和操作系统上的改进，能够高效支持大规模线程调度。

否则，就需要开发人员自己进行任务分割和调度，协程就存在流行的土壤。


【 在 mopo 的大作中提到: 】
: 好不好不知道，反正我编程10多年还真没怎么碰见过直接用协程的业务代码，就算是library也是凤毛麟角，也没出现过做架构和解决方案时非用不可的场景
: 对于并行和并发，实际情况是能把多线程玩好的已经不多了，单线程内做到伪并行也有很多路子，这个我一般交给专业的lib来做不会尝试自己造轮子
--
FROM 223.72.89.*

我是从多进程，多线程，线程池一路走来，遇到了协程需求。
你们是一开始就站在协程角度看问题，所以不同。
没关系，百花齐放，方案摆在这里，有意者选用。
楼主认为不好，可以不用。也可以在这里学习一下，看看协程到底有多少种用法。我贡献一种。
【 在 hgoldfish 的大作中提到: 】
: 其实你们想的这些事情，几乎每个方案都有现实的例子。
: 比如 python 和 js 的协程就是不跨线程的。c++20 目前的几个实现应该也是不跨线程的。
: 而 c#, java, go 都是跨线程的。
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*

我觉得不是这样的呢。以前协程的使用成本比较高，需要修改引入第三方库。还有各种适配的 BUG。使用经验也不足。所以你看本版还在讨论协程该怎么用，要怎么实现这些事。

现在各种主流语言都标配协程了。后面大家会越用越熟练。直到最后，大家会发现所有函数指针、回调函数到最后都不必要的。那时系统架构与具体的编程细节都会迁移到协程架构来。

协程是一种新的架构。比如 Erlang 的 Actor, golang 的 CPS 都会对系统架构造成重大的冲击。

【 在 finlab 的大作中提到: 】
: 现在协程流行的原因，还是线程的成本太高。
: 一个是现在的cpu每个核心有独立缓存，一个线程固定分配到一个核心是最好的，如果线程反复随机调度到不同核心，就会导致缓存的效率大幅下降，
: 另一个是操作系统层面，线程是一个比较重的对象，操作系统支持的线程数量上限也不高。
: ...................
--
修改:hgoldfish FROM 27.154.110.*
FROM 27.154.110.*

主要还是C++的协程规范搞得晚了，别的语言都用了多久了，而且是大规模使用，肯定可以积累好的实践和规范。

乱搞那肯定是没法维护的，就跟乱throw、乱catch异常一样


【 在 DoorWay 的大作中提到: 】
: 开发者更容易理解，版面就不会这么多大佬一直在讨论了。
: 我看是更容易一知半解。上手就干。
: 协程好调试是相对什么说的，我觉得是更难调试了。
: ...................
--
FROM 114.241.228.*

一个月？！哥们，1个月哪行呀，4个月！
一天改的代码，在原有线程池基础上，改出协程。一周之内能够稳定运行，不能投产呀！必须进行大量的压力测试，不断发现问题，不断解决问题，最后4个月定稿。
这个就是不用任何轮子的代价吧，因为这个协程必须与原有系统兼容，没办法使用现成的。
举个例子，一个协程，刚刚把自己的context加入epoll，就被另一个线程resume了，这边还没有完成swapcontext呢。发生撞车了（一个协程出现在两个线程），概率很低。怎么解决？
【 在 DoorWay 的大作中提到: 】
: 开发者更容易理解，版面就不会这么多大佬一直在讨论了。
: 我看是更容易一知半解。上手就干。
: 协程好调试是相对什么说的，我觉得是更难调试了。
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*