关于永远不会完成的 Scala Future 及其对其他回调的影响的说明答案

【问题标题】：Clarification about Scala Future that never complete and its effect on other callbacks关于永远不会完成的 Scala Future 及其对其他回调的影响的说明
【发布时间】：2014-03-17 20:07:32
【问题描述】：

在重新阅读 scala.lan.org 详细介绍 Future here 的页面时，我偶然发现了以下句子：

如果某些回调从未完成（例如回调包含无限循环），则其他回调可能根本不会执行。在这些情况下，潜在的阻塞回调必须使用阻塞构造（见下文）。

为什么其他回调不会被执行？我可能会为给定的 Future 安装一些回调。完成 Future 的线程可能会也可能不会执行回调。但是，因为一个回调没有玩脚踢，其余的不应该受到惩罚，我认为。

我能想到的一种可能性是 ExecutionContext 的配置方式。如果它配置有一个线程，那么可能会发生，但这是一种特定行为，通常不是预期的行为。

我在这里遗漏了一些明显的东西吗？

【问题讨论】：

“但这是一种特定的行为，通常不是预期的行为”：或者换句话说，这可能发生（回调永远不会执行）。这似乎与您引用的文字所说的完全一致。
@RégisJean-Gilles 同意你的解释。事实上，你的观点强调了我的推论，如果我在回调中管理可能永无止境的计算时不小心，我可能会对其他回调感到惊讶。我的观点是，关于未来的文章可以举例说明这种可能的后果；否则听起来有些模糊。你怎么看？我只是好奇别人的看法。

标签： scala callback future

【解决方案1】：

回调在ExecutionContext 中调用，该ExecutionContext 具有最终有限的线程数 - 如果不是由特定的上下文实现，那么由底层操作系统和/或硬件本身调用。

假设您的系统的限制是OS_LIMIT 线程。您创建 OS_LIMIT + 1 回调。从这些中，OS_LIMIT 回调会立即获得一个线程 - 并且没有一个会终止。

如何保证剩余的 1 个回调永远获得线程？

当然，Scala 库中可能内置了一些检测机制，但在一般情况下不可能做出最佳实现：也许您希望回调运行一个月。

相反（这似乎是 Scala 库中的方法），您可以提供工具来处理您（开发人员）知道有风险的情况。这消除了系统中的惊喜元素。

也许最重要的是 - 它使开发人员能够将有关处理程序/任务特征的必要信息直接写入他/她的程序，而不是依赖于某些晦涩难懂的语言功能（可能会因版本而异）。

【讨论】：

请注意，即使有“放弃”线程的能力，情况最终也会随着缩放而减少到相同的情况。
@TheTerribleSwitftTomato ：'它使开发人员能够..' - 你能详细说明一下吗？我肯定错过了提示，但是我要“烘烤”什么以及如何烘烤？如果我以这样一种方式构造回调，即它们的数量总是比 OS_THREADS 少 2（主线程为 1），你会认为这是一种合理的方法吗？但是，一个正在运行的应用程序可能定义了许多这样的回调，并且何时调用是未知的。
@Nirmalya ：“什么”是诸如“此回调可能被前面的代码无限期阻止”、“如何”之类的信息——通过使用提供的 API，例如 Await.result。我不确定我是否理解你的其余问题。无论如何，我想指出的是，我们正在讨论标准库开发人员的观点，他们必须考虑任何和所有应用程序。
@TheTerribleSwitftTomato：（标准库开发人员的观点）点了！我仍然认为Future（scala.lang.org）上的文章应该详细说明这一点。
@Nirmalya ：很高兴我提供了对您有用的解释。关于详细说明 - 这可能确实是一个好主意。而且，实际上，没有什么可以阻止您访问leaving feedback（右侧）:)。