JavaScript Transferable Objects：为什么引擎不保留原始实例？答案

【问题标题】：JavaScript Transferable Objects: Why doesn't the engine preserve the original instance?JavaScript Transferable Objects：为什么引擎不保留原始实例？
【发布时间】：2017-10-27 06:13:13
【问题描述】：

我正在阅读this article on web workers，我遇到了关于可转移对象的这一部分：

使用 Transferable Objects，数据可以从一个上下文传输到另一个上下文。它是零拷贝，极大地提高了向 Worker 发送数据的性能。如果您来自 C/C++ 世界，请将其视为传递引用。但是，与传递引用不同的是，调用上下文中的“版本”在转移到新上下文后将不再可用。

为什么？根据我对抽象堆栈机器的理解，可以保留原始指针似乎是完全合理的。诚然，由于数据现在是从另一个上下文中引用的，因此继续使用它将是一项棘手的任务，但并非完全不合理。为什么原始对象被清除了？

如果有人对此有一些有价值的见解，我还想了解整个过程是如何在幕后进行的。

【问题讨论】：

因为这是转让它而不是分享它的全部意义：无法继续使用它，所以（你可以请确保）您不必处理线程安全的棘手问题。
谢谢你，@Bergi。你知道这个设计决定是否在 JS 社区中引起争论吗？还是来回传输被普遍认为是最优雅、最好的整体解决方案？
我看不出那个解决方案有什么问题，为什么你会设计它不同 - 如果你这样做了，它就不会再被称为“可转移对象”了。如果您想要继续处理数据，并且能够处理棘手的问题，there's shared memory as well。您只需选择您需要的。

标签： javascript web-worker transferable

【解决方案1】：

传输对象的一个可能原因是减少用于存储同一对象的多个副本的内存量。

2.7.2 Transferable objects

可传输对象支持跨事件循环传输。传输是在共享对象的同时有效地重新创建对象引用基础数据，然后分离对象转移。这对于转移昂贵的所有权很有用资源。不是所有的对象都是可转移的对象，也不是所有的作为可转移对象的对象的各个方面必然是转移时保留。

注意：转移是一种不可逆且非幂等的操作。一旦一个对象已被转让，不能转让，或确实被使用，再次。

Platform objects 可以是可转移对象，如果它们只实现用[Transferable] IDL 扩展属性修饰的接口。此类接口还必须定义以下算法：

转移步骤，获取平台对象值和记录dataHolder

将值数据转换为的一组步骤 dataHolder 的字段。 dataHolder 中保存的结果数据必须独立于任何 JavaScript Realm。

如果无法进行转移，这些步骤可能会引发异常。

转收步骤，获取记录dataHolder和平台对象value

一组步骤，接收dataHolder 中的数据，并根据需要使用它来设置value。 value 将是相关平台对象类型的新创建实例，没有设置其内部数据；设置就是这些步骤的工作。

如果无法接收传输，这些步骤可能会引发异常。

由各个平台对象的定义决定通过这些步骤传输哪些数据。通常，这些步骤非常对称。

另见2.9.2. Transferable objects

【讨论】：