为什么`box :: new`不返回`Option`或`Result`？

Question

我不明白为什么Box::new不退还Option或Result.

分配可能会失败,因为内存不是无限制的,或者其他可能发生的事情; 这种情况下的行为是什么？我找不到任何有关它的信息.

Answer 1

更一般的形式是在内存不足(OOM)上做什么？

处理OOM有很多困难:

• 检测它,
• 从中恢复(优雅地),
• 将它整合到语言中(优雅地).

第一个问题是检测它.如今,许多操作系统默认使用交换空间.在这种情况下,在进入OOM情况之前,您的进程实际上遇到了麻烦,因为开始使用交换空间会显着减慢进程.当更高的进程需要更多内存(OOM杀手)时,其他操作系统会杀死低优先级进程,或承诺比现有内存更多的内存,希望它不会被使用或在必要时可用(过度使用),等等...

第二个问题是恢复.在进程级别,恢复的唯一方法是释放内存...而不是在平均时间内分配任何内存.这并不像听起来那么容易,例如,不能保证恐慌和退绕不需要分配内存(例如,如果不小心完成,存储恐慌消息的行为可以分配).这就是为什么当前的rustc运行时默认在OOM上中止.

第三个问题是语言集成:内存分配无处不在.任何使用Box,Vec,String等...所以,如果你顺恐慌路线,并使用Result路由,而不是,你需要调整几乎任何不同诱变方法签名来解释这种类型的故障,并在所有的接口这将泡沫.

最后,这是值得注意的是,在内存分配失败需要处理域...很多时候,内存分配是不容许的开始.例如,在关键的嵌入式软件中,所有内存都是预先分配的,并且有一个证明,即不需要分配的内容.

这很重要,因为它意味着很少有这样的情况:(1)允许动态内存分配;(2)它的失败必须由进程本身优雅地处理.

在这一点上,人们只能想知道应该在这方面花费多少复杂性预算,以及这将推动99%不关心的程序的复杂程度.

Answer 2

我发现Rust开发人员之间就liballoc中的一些低级函数没有返回Options:PR#14230进行了以下通信.

特别是以下部分解释了其背后的一些原因:

huonw:

嗯......最低级别的库不应该触发任务失败吗？我们是否计划让任何较低级别的库返回Option或其他东西？

alexcrichton:

我发现想要触发任务失败是很常见的,远比我最初意识到的要多.我还发现所有上下文都有某种形式或失败的概念,尽管它并不总是任务失败.

huonw:

我从任务失败的角度思考不能在呼叫站点恢复,即更高级别的库可以自由失败,但是绝对最低的构建块不应该,因此人们可以按照自己的意愿处理问题(即使它是只需手动触发任务失败).如果liballoc不是最低级别的分配库,那么失败就没问题了.(顺便说一句,我想你可能误解了我的评论,因为我不是在谈论libcore,只是liballoc.)

alexcrichton:

哎呀,对不起!我相信核心分配器接口(位于liballoc中)将被指定为不会失败!(),只是它们之上的基元(例如,box运算符).

也许我们可以扩展box语法以允许返回Option一天来适应这个用例,因为我肯定希望能够重用这段代码!

Answer 3

这是语言设计决策.您不仅要考虑单个操作的逻辑(Box::new例如),还要考虑它将如何影响语言的人体工程学.如果我们用机制来处理内存分配错误,Return那么这些错误几乎会在各处开始冒泡.即使该方法不堆上分配任何内存目前,它可能诉诸它在未来.突然之间,一个简单的实现变化将被卡住,因为你必须改变API,语义版本控制意味着一个主要版本.所有这些都有一点好处,因为在存在交换和内存杀手的情况下,内存处理不是非常可靠或有用(通常你应该在内存不足错误之前停止分配内存).

在 reddit上讨论了很多主题.

我看到的一个建议的解决方案是将内存不足视为恐慌,解除并终止相应的任务.