协程很多场合是为了节省线程切换的成本，提高cpu的利用率。

但是经常把一个事情劈成两半，绕了半天还是要再捏到一起。

既然协程这么流行，那就不如在cpu和操作系统、编译器层面进行优化，

降低线程上下文的切换开销，统一使用线程来完成cpu的分时复用。
--
FROM 223.72.70.*

一般情况并不需要协程。
只有异步IO时，将它表达为同步，才需要。
简单点，在线程池网络编程中，长时间的同步IO，占用线程时间太长，影响别的任务。在等待IO期间，释放线程，由一个协程等待IO。
对于单线程协程，可以理解为只有一个线程的线程池，如果需要处理很多的连接，协程是必须的。
看起来是一个read函数，返回时已经完成了IO，就是同步过程。其实中途线程跑掉了，干别的去了。
【 在 finlab 的大作中提到: 】
: 协程很多场合是为了节省线程切换的成本，提高cpu的利用率。
: 但是经常把一个事情劈成两半，绕了半天还是要再捏到一起。
: 既然协程这么流行，那就不如在cpu和操作系统、编译器层面进行优化，
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*

有时候不方便用多线程锁，用协程更容易写出可靠的代码。
--
FROM 171.213.205.*

有了协程，更象是有了一个确定性很强的状态机
但这个状态机又跟业务有关，好象不管是 内核｜编译器 ，都没有办法灵活地帮业务做一些定制
内核看着自己倒是可以用协程再提升一下性能，盲猜收益不会很大。
【 在 finlab 的大作中提到: 】
: 协程很多场合是为了节省线程切换的成本，提高cpu的利用率。
: 但是经常把一个事情劈成两半，绕了半天还是要再捏到一起。
: 既然协程这么流行，那就不如在cpu和操作系统、编译器层面进行优化，
: ...................
--
FROM 116.76.169.*

协程机制与线程混用带来更高 的复杂性。


异步调用到最后，还是要同步，不如一开始就同步。

比如，await readAsyn(); await processAsyn()  这种模式不过是为了让出空闲时间的控制权。

不如就在底层实现同步的read，process， 上层就直接 顺序调用，

让操作系统或编译器层面解决线程空闲的调度。






【 在 poocp 的大作中提到: 】
: 你说了半天，这些问题还是多线程带来的啊。
:
--
FROM 223.72.70.*