SynchronousStreamController 类 抽象 接口

这是一个同步地发送其事件的流控制器。

同步流控制器适用于已异步事件引发流事件的情况。

与在更晚的微任务中将事件添加到流中相比，从而产生额外的延迟相反，事件将由同步流控制器即时触发，就像流事件是当前事件或微任务一样。

同步流控制器可用于破坏 Stream 的契约，并且必须小心使用，避免这样做。

使用 SynchronousStreamController 而不是正常 StreamController 的唯一优点是改进了延迟。只有当改进非常显著且使用安全时，才应使用同步版本。否则，只需使用正常的流控制器，它将为 Stream 始终提供正确的行为，而且不会意外地破坏其他代码。

向同步控制器添加事件应仅发生在处理原始事件的最后。在那个点上，将事件添加到流中相当于回到事件循环并在下一个微任务中添加事件。

每个监听器回调将像顶级事件或微任务一样运行。这意味着如果它抛出异常，错误将尽可能快地报告为未捕获的。这是将事件添加为原始事件处理器的最后一件事的原因之一 – 任何在添加事件之后执行的操作都将延迟在事件监听器回调中报告错误。

如果在未知为另一事件的环境中添加事件，可能会在监听器准备好处理它之前，使流监听器得到该事件。我们承诺在调用 Stream.listen 之后，直到执行监听代码的代码完成之前，不会获取任何事件。相应于未知来源的函数调用调用 add 可能会破坏这个承诺。

控制器来自 onListen 的回调 不是 异步事件，并且在 onListen 回调中向控制器添加事件总是错误的。这些事件会在监听器收到订阅之前就传递。

同步广播流控制器还有一个普通流控制器没有的限制：在事件传递过程中，不应调用 add、addError、close 和 addStream 方法。也就是说，如果控制器流上的订阅的回调调用上述函数中的任何函数，则调用将失败。广播流可能有多个监听器，如果在添加另一个事件的同时同步添加事件，后面的事件可能会在先前的到达某些监听器。为了避免这种情况，在先前的事件被触发时，不能添加事件。这保证了在首次调用 add、addError 或 close 返回之后，事件将按正确顺序传递。

这仅保证事件被传递到订阅。如果订阅被暂停，实际的回调可能会稍后发生，并且事件将被订阅器缓冲。除非暂停，以及以下尚未传递的已缓冲的事件，否则，在添加事件时，回调将同步调用。

在另一个事件正在进行中时，向同步非广播流控制器添加事件可能导致第二个事件延迟，并且无法同步发送。在此事件发送完毕之前，控制器不会同步操作。