同步读/写端口时避免递归？答案

【问题标题】：Avoiding recursion when reading/writing a port synchronously?同步读/写端口时避免递归？
【发布时间】：2013-11-26 05:23:19
【问题描述】：

Rebol 3 中的所有端口操作都是异步的。我能找到进行同步通信的唯一方法是调用wait。

但是在这种情况下调用 wait 的问题是它会检查所有打开端口的事件（即使它们不在传递给 wait 的端口块中）。然后他们调用他们的响应事件处理程序，但可以在其中一个事件处理程序中完成读/写。这可能会导致递归调用“等待”。

我该如何解决这个问题？

【问题讨论】：

实际上，我认为在当前的 R3 实现中没有解决方案，所以我继续为“等待”添加一个“/only”改进，它只会等待在提供给“等待”的端口上，从而避免递归调用。请参阅我的拉取请求：github.com/rebol/rebol/pull/177
出于好奇，为什么需要同步？
在很多情况下使用同步端口编码要容易得多：假设您想通过单击按钮发送电子邮件，并报告它是成功还是失败。在做任何其他事情之前等待它完成要容易得多。
你一定要使用 Rebol 吗？
是的。这实际上更多是关于 Rebol 3 的问题，而不是一般的同步通信。

【解决方案1】：

您可以只使用锁。 Cummunication1 可以设置一些全局锁定状态，即使用变量（确保它是线程安全的）。 locked = true。然后 Communication2 可以等到它被解锁。

loop do
    sleep 10ms
    break if not locked
end
locked = true
handle_communication()

【讨论】：

【解决方案2】：

在只有异步事件并且我们需要同步回复的情况下，启动计时器或休眠超时，如果满足处理程序或所需目标，则说真，否则假并确保事件被取消/如果关键，请重新设置。

【讨论】：

【解决方案3】：

为什么不创建一种“缓冲区”函数来接收来自异步条目的所有消息并将它们作为 FIFO（先进先出）处理？

这样您可以保持端口的异步特性并在同步模式下处理它们。

【讨论】：

【解决方案4】：

我认为存在 2 个设计问题（可能是手头的工具/解决方案所固有的）。

Wait 做得太多 - it will check events for all open ports。在一个健全的环境中，等待应该只在需要的地方实现：每个设备、每个端口、每个套接字……在共享资源之间创建不必要的相互依赖关系不能很好地结束——尤其是知道共享资源（即使没有相互依赖关系）会产生很多问题。
事件处理程序可能做得太多。事件处理程序应该尽可能短，并且它应该只处理事件。如果 is 做得更多，那么处理程序做得太多 - 特别是如果涉及其他共享资源。在许多情况下，处理程序只是保存将丢失的数据，否则会丢失；而异步作业会做更复杂的事情。

【讨论】：