为什么meteor.js是同步的？答案

【问题标题】：Why is meteor.js synchronous?为什么meteor.js是同步的？
【发布时间】：2012-08-22 10:00:58
【问题描述】：

代码同步不会影响效率吗？为什么同步编码是一种胜利？我在做一些研究时发现了这两个链接：http://bjouhier.wordpress.com/2012/03/11/fibers-and-threads-in-node-js-what-for/，https://github.com/Sage/streamlinejs/

如果目标是防止意大利面条式代码，那么显然您可以使用异步代码，例如 streamline.js，这不是回调金字塔，对吧？

【问题讨论】：

【解决方案1】：

你必须在这里区分两件事：

节点的fs.readFileSync、fs.statSync 等同步函数。所有这些函数的名称中都有Sync (*)。这些函数是真正的同步和阻塞。如果你调用它们，你会阻塞事件循环并杀死节点的性能。您应该只在服务器的初始化脚本（或命令行脚本）中使用这些函数。
fibers 或 streamline.js 等库和工具。这些解决方案允许您以同步风格 编写代码，但您使用它们编写的代码仍将异步执行。他们确实不会阻塞事件循环。

(*) require 也被阻塞了。

Meteor 使用纤维。它的代码是用同步风格编写的，但它是非阻塞的。

胜利不在于性能方面（这些解决方案有自己的开销，因此它们可能会稍微慢一些，但它们也可以比缓存等特定代码模式的原始回调做得更好）。胜利以及开发这些解决方案的原因在于可用性方面：它们让您以同步风格编写代码，即使您正在调用异步函数。

2017 年 1 月 25 日编辑：我创建了 3 个要点来说明非阻塞纤维： fibers-does-not-block.js、fibers-sleep-sequential.js、fibers-sleep-parallel.js

【讨论】：

“它们不会阻塞事件循环。”该声明具有误导性，因为纤程必须在关键部分阻塞事件循环。由开发人员决定关键部分是什么并适当地使用纤维。
@asim。这是错误的：纤程是非抢占式的； Fiber 之间的上下文切换由 libcoro 实现，并且与事件循环完全解耦。
我很困惑。如果我将 i/o 操作放在纤程中，在 fiber.run() Fiber.yield() 命令之间，那么程序的其余部分将等到该部分代码执行。怎么不堵？我是不是误会了什么？
您的光纤将启动 I/O 操作，然后调用 Fiber.yield()。这个产量将保存上下文并将控制权转移到将处理所有回调的主循环，像往常一样。当您的 I/O 回调最终触发时，它将从主循环调用 fiber.run() 以恢复之前产生的纤程的执行。事件循环永远不会被阻塞；它在您的代码出现阻止Fiber.yield() 时运行。与async/await 相同：主循环在您的代码等待的任何地方运行。
我创建了一个小要点来说明在Fiber.yield() 期间触发的回调：gist.github.com/bjouhier/7d660269b6fae13b7e33081d391c665d

【解决方案2】：

使用streamlinejs 之类的代码时，代码不是“同步”的。实际代码将仍然异步运行。写很多匿名回调函数不是很漂亮，这就是这些东西的帮助。

【讨论】：