同步发射事件是否不正确？答案

【问题标题】：Is emitting events synchronously incorrect?同步发射事件是否不正确？
【发布时间】：2012-03-20 13:41:34
【问题描述】：

在任何将存在的系统中，附加侦听器都是异步的。任何使用事件驱动风格的系统都会异步发出事件。没有妥协，以任何其他方式这样做都是错误的

事件发射应该总是异步的吗？

【问题讨论】：

这是从某个地方引用的吗？
@missingno 这只是我引用同事的话。
为什么不将.forEach 视为某种事件系统？

【解决方案1】：

应该的。

事件发射器只不过是一个大循环，它为给定的事件（字符串）调用许多函数。想象一下，一个事件有数千或数十万个绑定的侦听器（函数），我们需要调度该事件类型。如果该调度同步发生，我们将挂起并搞砸整个应用程序，直到调用所有函数。由于事件发射器通常与松散耦合的架构并驾齐驱，这将是可怕的。

在这个过程中一定存在某种异步。

【讨论】：

dispatchEvent 是同步的。节点的EventEmitter 是同步的
@Raynos：这意味着我在这篇文章中的示例将适用于节点？
Communications.dispatch 是同步的
@Raynos：是的，我只有setTimeout 覆盖了整个通话。但它仍然不是好的设计。 dispatch 应该使用超时本身来触发我猜的所有侦听器。
@jAndy，您认为在每个事件处理程序调用之间添加至少 10 毫秒的延迟是件好事吗？

【解决方案2】：

有一些同步使用事件发射器的用例，因为有一种设计模式的味道，但我认为这没什么意义。如果这实际上是您的应用程序正在执行的操作，那么您应该始终尝试在调用所有其他函数时调用一个函数。同步事件发射器并非完全不常见，但我确实认为它们是一个糟糕的设计选择，应该避免使用。

我可能还应该提到同步事件发射器在 JavaScript 中是有意义的，当您想要模拟发生的事件以进行测试时，但我确实认为它应该由异步事件发射器驱动。

【讨论】：

【解决方案3】：

不，不应该。

仅仅因为您发出事件并不意味着发出或处理需要是异步的。

您的事件处理不应依赖于同步运行。

例如，大多数 GUI 框架都是基于事件的并在单个线程中运行。

【讨论】：

GUI 异步接收用户的输入。在 GUI 中使用事件驱动编程的全部意义在于提高感知响应能力。您可能会在一个线程上按顺序处理我的事件，就像在 JavaScript 事件处理中发生的那样，但您并没有阻止我将多个事件排队等待处理。你尽快释放我，用户，事件发射器。当您仍在处理第一个时，我可以在浏览器中进行多次单击。 Asycn 发射器与侦听器的并发执行不同。

【解决方案4】：

这是一个老问题，但我不同意这些回答。我认为正确的答案是没有永远正确的答案。人们已经引用了异步的原因，这些原因是正确的，但在其他情况下，同步更可取。我使用了一个 PubSub 库，它方便地具有 publish() 和 publishSync() 方法以允许两者（默认为异步）。

您需要同步的一种情况是，您希望所有侦听器都可以访问事件发生时的当前状态。

关于异步调用是非阻塞的，因此允许单线程 UI 更新（如在 JavaScript 中）的论点，这在一定程度上是正确的。如果您有一个不断更新的 UI（即动画），那么您现在做一些耗时的事情与“以后”耗时的事情无关紧要；无论哪种方式，如果它很耗时，它都会阻止动画并降低帧速率。我有时更喜欢让所有这些同步，因为运行到完成有好处，而且我可以更轻松地测试和配置文件以确保我的所有侦听器都在累积处理1/fps 时间。异步侦听器不仅推卸责任，而且使分析变得更加棘手。

“不知道”在构建时或编译时调用什么侦听器以使组件彼此不知道与“不知道”之间存在差异。能够知道您的应用程序中存在哪些其他组件以及谁注册了侦听器。可以说，即使您是唯一的程序员，在后一种意义上假装不知道也有好处（例如，这使您不必对自己的代码库的未来更改做出太多假设），但是您也可以说应该，作为一个人，知道基本上有这 5 个组件注册了十几个听众来做这么多的工作，而不是可能有无限数量的听众在做谁知道什么工作。后者通常是极端的（过早的？）优化。简单地调用异步允许一个人不知道后者的想法是有缺陷的。异步不会神奇地购买无限的处理时间。单个听众也不能比发声者或程序员更了解他们被允许处理多少时间。（好吧，如果事件系统包含此信息，他们可以，但这超出了 pubsub 模式。）

【讨论】：