Add immutable array buffer awareness to structuredClone #11033
Conversation
|
Can you work on getting the build passing? Also, it would be good to update the PR title and commit message to specify that this is about preventing transferring of such immutable array buffers; structured cloning them is still allowed. |
source
Outdated
| @@ -10463,7 +10464,8 @@ o.myself = o;</code></pre> | |||
| <span>"<code>DataCloneError</code>"</span> <code>DOMException</code>.</p></li> | |||
|
|
|||
| <li><p>If <var>transferable</var> has an [[ArrayBufferData]] internal slot and | |||
| <span>IsSharedArrayBuffer</span>(<var>transferable</var>) is true, then throw a | |||
| <span>IsSharedArrayBuffer</span>(<var>transferable</var>) is true or | |||
There was a problem hiding this comment.
Nit:
| <span>IsSharedArrayBuffer</span>(<var>transferable</var>) is true or | |
| either <span>IsSharedArrayBuffer</span>(<var>transferable</var>) is true or |
since otherwise a valid reading at least at first glance is "(transferable has an [[ArrayBufferData]] internal slot and IsSharedArrayBuffer(transferable) is true) or IsImmutableBuffer(transferable) is true)".
|
Cloning should preserve immutability (tc39/proposal-immutable-arraybuffer#19 (comment)), the same way it currently preserves resizability. |
gibson042
changed the title
gibson042
force-pushed
the
structured-clone-immutable-arraybuffer
branch
from
ef5df7e to
2f4d3cb
Compare
Done.
Done.
Done: 2f4d3cb |
gibson042
changed the title
source
Outdated
| <li><p>Set <var>serialized</var> to { [[Type]]: "ImmutableArrayBuffer", [[ArrayBufferData]]: | ||
| <var>value</var>.[[ArrayBufferData]], [[ArrayBufferByteLength]]: | ||
| <var>value</var>.[[ArrayBufferByteLength]] }.</p></li> |
There was a problem hiding this comment.
Is value.[[ArrayBufferData]] supposed to be able to be kept alive in the serialization? Unlike for SABs, serializing immutable ArrayBuffers doesn't throw if forStorage is true, meaning that the serialization could be deserialized at some future time in a different process that doesn't share any memory with the current one.
At the very least we should have a note saying that implementations should make sure that a forStorage serialization actually serializes the buffer's contents, but a non-for-storage one might serialize a pointer to the buffer data instead.
There was a problem hiding this comment.
Is
value.[[ArrayBufferData]]supposed to be able to be kept alive in the serialization? Unlike for SABs, serializing immutable ArrayBuffers doesn't throw if forStorage is true, meaning that the serialization could be deserialized at some future time in a different process that doesn't share any memory with the current one.
That's a good question. I'm not very well versed in the particulars here, but my instinct is that I've got it correct—an immutable array buffer should behave like any other non-shared array buffer when forStorage is true, such that it could be deserialized into a new immutable array buffer with identical contents by a completely independent process at some point in the future.
I like your idea of a note, and have attempted to update accordingly.
…ith forStorage true vs. false
| [[ArrayBufferData]] internal slot value is <var>serialized</var>.[[ArrayBufferData]], whose | ||
| [[ArrayBufferByteLength]] internal slot value is | ||
| <var>serialized</var>.[[ArrayBufferByteLength]], and whose [[ArrayBufferIsImmutable]] internal | ||
| slot is present.</p></li> |
There was a problem hiding this comment.
Is it possible for a slot to not have a value in this way?
There was a problem hiding this comment.
Technically yes, but it's obviously not great and I see now that things are moving away from it. I've updated accordingly.
There was a problem hiding this comment.
But for the record, the document.all HTMLAllCollection seems to be another example—it has an [[IsHTMLDDA]] internal slot for which no value is ever specified AFAICT.
There was a problem hiding this comment.
And in ECMAScript, Object Internal Methods and Internal Slots defines the initial value of an internal slot to be undefined.
There was a problem hiding this comment.
True although see also tc39/ecma262#3399
…uffer with forStorage true vs. false
…hich are not detachable)
Ref tc39/proposal-immutable-arraybuffer#30
Immutable ArrayBuffers is currently at Stage 2, but seeking advancement in next week's Ecma TC39 meeting. Because immutable ArrayBuffers cannot be detached,
structuredCloneshould perform the relevant test.(See WHATWG Working Mode: Changes for more details.)
/infrastructure.html ( diff )
/structured-data.html ( diff )