- 主题:觉得协程不是一个太好的编程模型
大量线程才效率低。那真是全干调度了。
最好是等于核数，多一两个无妨，太多效率会严重降低。
【 在 finlab 的大作中提到: 】
: 我理想的模型是，设法降低单个线程的开销，然后创建大规模的线程池。
: 就不用担心线程阻塞不够用。系统会简单很多。
:
: ...................
--
FROM 221.218.60.*
在大迸发的网络环境下，一个协程，被一个事件激活，就在某个线程内执行，不到IO时刻，一直都不会被调度。占死这个线程。此时期如果有别的激活，就有别的线程来干。直到它需要IO，且完不成，才会yield，下次resume不一定是哪个线程接手。
线程数＝核数，线程执行期间就不会经常被打扰，发生切换，尽量减少切换开销。线程太多就会经常切换，轮流执行，才会发生切换开销问题。
线程池也避免了线程反复创建销毁的开销。一旦创建永不销毁。没事就在epoll＿wait。
有啥问题？
【 在 VincentGe 的大作中提到: 】
: 那你这么做还是有问题。
: 协程不是一个独立的模块存在，它在执行时一定位于某一个线程内。它的设计本身就是单线程模型内的并发模型（不并行）
: 按照你说的，它和异步任务相似。协程调度器持有一个类似线程池的东西，将异步任务调度到某一线程线程执行。
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*
这完全可以从软件架构上解决。
比如对于 web 系统，系统里面有多少个核心，就启动多少个进程，大家一起抢请求就行了。本来 web 系统为了横向多机扩展，也得进程+协程的架构。
而对于一些 OLAP 类的应用，需要共享使用大量资源，问题也不大，一般仍然可以拆分出多种业务形态。
其实吧，本身拆进程就能让服务更加稳定。一个进程挂掉，还有另外的进程可以服务。
【 在 ylh1969 的大作中提到: 】
: 如果协程只能困守在一个线程，那么负载均衡就是一个问题，没有办法高效率的使用多核。
: 这个损失，可比线程协程调度时间那点差异大太多啦。
--
FROM 120.41.147.*
可以配置 go 让 goroutine 也只跑在一个线程里面。
然后启动多个 go 进程。
【 在 VincentGe 的大作中提到: 】
: 两者就不是一个并发模型，他们的差异实际上非常大。
: async/await 是协作式的，他们本身就在一个线程内。
: spawn，go的语法更多的类似异步任务的概念。
: ...................
--
修改:hgoldfish FROM 120.41.147.*
FROM 120.41.147.*
你想的事情，golang 和 java 都是这样的啊。
但是在编程的时候，访问共享资源的时候，就得注意加锁了。
golang 推荐使用 chan 来解决访问共享资源互斥的问题。全都转成了管道通信。
golang 这个模式叫做 CPS，有个类似的 Erlang 的 Actor.
这俩底层都是在多个核心上面跑的协程。
【 在 finlab 的大作中提到: 】
: 我理想的模型是，设法降低单个线程的开销，然后创建大规模的线程池。
: 就不用担心线程阻塞不够用。系统会简单很多。
: 叱滩痘瘛
: ...................
--
FROM 120.41.147.*
其实你们想的这些事情，几乎每个方案都有现实的例子。
比如 python 和 js 的协程就是不跨线程的。c++20 目前的几个实现应该也是不跨线程的。
而 c#, java, go 都是跨线程的。
只能说大家都活得不错。都有人用。各有优势劣势。没必要非彼即此。
【 在 ylh1969 的大作中提到: 】
: 不跨线程挺麻烦，跨线程反而简单。
--
修改:hgoldfish FROM 120.41.147.*
FROM 120.41.147.*
可以。拆进程前面也得有负载均衡。
【 在 hgoldfish 的大作中提到: 】
: 这完全可以从软件架构上解决。
: 比如对于 web 系统，系统里面有多少个核心，就启动多少个进程，大家一起抢请求就行了。本来 web 系统为了横向多机扩展，也得进程+协程的架构。
: 而对于一些 OLAP 类的应用，需要共享使用大量资源，问题也不大，一般仍然可以拆分出多种业务形态。
: ...................
--
FROM 221.218.60.*
大家讨论嘛，我贡献我的方案。
【 在 hgoldfish 的大作中提到: 】
: 其实你们想的这些事情，几乎每个方案都有现实的例子。
: 比如 python 和 js 的协程就是不跨线程的。c++20 目前的几个实现应该也是不跨线程的。
: 而 c#, java, go 都是跨线程的。
: ...................
--
FROM 221.218.60.*
好不好不知道，反正我编程10多年还真没怎么碰见过直接用协程的业务代码，就算是library也是凤毛麟角，也没出现过做架构和解决方案时非用不可的场景
对于并行和并发，实际情况是能把多线程玩好的已经不多了，单线程内做到伪并行也有很多路子，这个我一般交给专业的lib来做不会尝试自己造轮子
--
FROM 219.142.253.*
多少才算太多？
【 在 ylh1969 的大作中提到: 】
: 大量线程才效率低。那真是全干调度了。
: 最好是等于核数，多一两个无妨，太多效率会严重降低。
--
FROM 219.142.253.*