探讨这个问题之前需要引入一个极端负载, 就是一个死循环的程序.
但是死循环程序也需要分两种, 一种不做调用就是空转, 一种会做函数/系统调用.
然后考虑引入这种负载之后会对正常应用有啥影响.
而且需要非常明确的指出, 这种问题操作系统已经解决的很好了(前提是进程隔离).
(这里无视并发性, 回到传统的 fork 模式只有开销大的限制)
如果因为这个问题出现了倒退, 那必然是语言或者框架的倒退,
coroutine 就是这样的东西, 如果你不主动找机会让出的话那就要一直跑下去了 (reactor 同理).
这样做就回到操作系统都不成熟的原始时代了 (哈哈哈).
---
先说 Erlang, 必须承认 Erlang 把这个问题解决的很好~ 不管是第一种还是第二种.
但是项目选型的人和研究的人的功劳要怎么算?
难道因为没重新发明轮子而一次性选对型了就有大功? 这应该是一项基本功...
---
作为对比, 要考虑一下 coroutine / reactor 系要怎么绕坑.
虽然从调度上需要自己想办法放弃处理器 (切换到别处去),
但本质问题还是将重负载分离出去, 这样基本就不会阻塞了.
这个本质问题两方都要面对, 只是因为 Erlang 有优秀的设计提高了隔离性, 影响范围小得多而且问题调查也更容易,
但是不等于 Erlang 一方完全不需要做分离的操作, 随便什么人都可以写对 (不过这个是有讨论余地的).
在拥有这个意识的前提下, 通过对框架为特定负载的优化以达到更高的吞吐量, 或者避免语言切换/再学习的代价等都是有价值的,
既然不存在某种框架一定做不了某种应用的说法,
那么框架或者语言在某一方面的缺陷, 需要通过对整体问题的分析与理解来绕过或者根本上解决, 而且当然是越早发现弄清楚越好以避免后期代价.
---
最后果然还是变成了对网络编程理解的高下的问题...
理解不彻底的人就要走弯路, 所以某场辩论还是有一个结果的,
只是偶获得这种知识的方式比较独特, 双方各自形成自主认识的原因偶是不清楚的, 这些事情还是要知情者来讲更好.
ps:
http://www.zhihu.com/question/27465406/answer/36806416
ps2:
2015.5.7 追加
在做代码设计的时候很容易区分 IO 倾向的负载和计算倾向的负载, 如果实际任务都是这种的话新手写的进程调度器也能用.
但实际工程中很容易出现分离不彻底的情况埋下隐患, 这时就应当感谢内核进程调度器在设计和工程上的完备性.
处理一般任务的 VM 在内核看来就属于混合负载, 在特定的情况下可能会退化并被认作计算倾向负载, 此时朴素的协程调度器会将问题放大并影响无辜负载.
简化并隔离是最简单的方法, 但挑战将是如何长期保持简单清晰而不混入复杂.
其他情况都需要用复杂的解法应对复杂, 工程上这同样是长期的挑战.