SynchronousStreamController<T> 类 抽象 接口

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

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

而不是在后续微任务中将事件添加到流中，从而造成额外的延迟，同步流控制器会立即发出事件，就像流事件是当前事件或微任务一样。

同步流控制器可以用来打破 Stream 的契约，必须谨慎使用，以避免这样做。

使用 SynchronousStreamController 而不是正常的 StreamController 的唯一优势是提高了延迟。只有在改进显著且使用安全的情况下才使用同步版本。否则，只需使用正常的流控制器，它将为 Stream 总是提供正确的行为，并且不会意外地破坏其他代码。

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

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

如果在一个未知为另一个事件的设置中添加事件，可能会在监听器准备好处理之前，使流监听器接收到该事件。我们承诺，在调用 Stream.listen 之后，直到执行监听的代码完成之前，你将不会收到任何事件。对未知来源的函数调用做出响应并调用 add 可能会破坏这一承诺。

控制器从 onListen 回调中的回调 不是 异步事件，在 onListen 回调中添加事件总是错误的。事件将在监听器收到订阅之前就被发送。

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

这仍然仅保证了事件被传递到订阅。如果订阅被暂停，实际的回调可能还会稍后发生，事件将被订阅缓冲。排除暂停以及尚未传递的以下缓冲事件，当添加事件时，回调将在同步中调用。

在另一个事件正在进行时向同步非广播流控制器添加事件可能会导致第二个事件延迟，并且不会同步传递，并且直到该事件传递，控制器将不会同步操作。