-
Notifications
You must be signed in to change notification settings - Fork 32
Using [[ArrayBufferData]] for shared memory makes SharedArrayBuffers transferable, contrary to intent #144
Comments
Sorry for not realizing the effect here--this seems like exactly why we shouldn't've done the change that I was pushing for. Reverting the change would be an acceptable path, but I like the idea to do the fix in HTML. |
@littledan, fixing HTML to have a tighter spec for is-transferable is pretty clean, imo. Now that we've made the change in this proposal I'm not eager to revert it. |
Does this issue still need to be open? |
@flagxor This is technically about the HTML spec. They are working on cleaning up the structured clone algorithm, whatwg/html#2421 is a good place to start. Until that's been landed this bug should probably stay open. (I don't see how the referenced bug is relevant here?) |
Fixes #2260 (by being the last in a set of fixes). Closes tc39/proposal-ecmascript-sharedmem#144 and closes tc39/proposal-ecmascript-sharedmem#65.
Additionally, define StructuredSerializeForStorage when for serializable objects need to be stored more persistently. Tests: web-platform-tests/wpt#5003. Fixes #2260 (by being the last in a set of fixes). Closes tc39/proposal-ecmascript-sharedmem#144 and closes tc39/proposal-ecmascript-sharedmem#65.
Additionally, define StructuredSerializeForStorage when for serializable objects need to be stored more persistently. Tests: web-platform-tests/wpt#5003. Fixes #2260 (by being the last in a set of fixes). Closes tc39/proposal-ecmascript-sharedmem#144 and closes tc39/proposal-ecmascript-sharedmem#65.
Additionally, define StructuredSerializeForStorage when for serializable objects need to be stored more persistently. Tests: web-platform-tests/wpt#5003. StructuredSerializeForStorage follow-up: * whatwg/notifications#99 * w3c/IndexedDB#197 Fixes #2260 (by being the last in a set of fixes). Closes tc39/proposal-ecmascript-sharedmem#144 and closes tc39/proposal-ecmascript-sharedmem#65.
This can be closed. |
Make it so. |
Additionally, define StructuredSerializeForStorage when for serializable objects need to be stored more persistently. Tests: web-platform-tests/wpt#5003. StructuredSerializeForStorage follow-up: * whatwg/notifications#99 * w3c/IndexedDB#197 Fixes whatwg#2260 (by being the last in a set of fixes). Closes tc39/proposal-ecmascript-sharedmem#144 and closes tc39/proposal-ecmascript-sharedmem#65.
Additionally, define StructuredSerializeForStorage when for serializable objects need to be stored more persistently. Tests: web-platform-tests/wpt#5003. StructuredSerializeForStorage follow-up: * whatwg/notifications#99 * w3c/IndexedDB#197 Fixes whatwg#2260 (by being the last in a set of fixes). Closes tc39/proposal-ecmascript-sharedmem#144 and closes tc39/proposal-ecmascript-sharedmem#65.
Additionally, define StructuredSerializeForStorage when for serializable objects need to be stored more persistently. Tests: web-platform-tests/wpt#5003. StructuredSerializeForStorage follow-up: * whatwg/notifications#99 * w3c/IndexedDB#197 Fixes whatwg#2260 (by being the last in a set of fixes). Closes tc39/proposal-ecmascript-sharedmem#144 and closes tc39/proposal-ecmascript-sharedmem#65.
According to the HTML spec, if an object has an [[ArrayBufferData]] internal slot that is not detached then the object is transferable, see https://html.spec.whatwg.org/multipage/infrastructure.html#istransferable.
Recently we made the change that we use [[ArrayBufferData]] even for a Shared Data Block, and this slot cannot become detached. This was a much-desired change. But roughly at the same time we decided that postMessage() should not allow for a SharedArrayBuffer in the transfer list, and this is now encoded in the SAB companion spec for DOM, see https://tc39.github.io/ecmascript_sharedmem/dom_shmem.html.
Clearly these decisions are not quite compatible. The fix is probably to hack up the HTML spec to discriminate better. This needs to be noted with greater specificity in section 1.5 of our DOM companion spec.
The text was updated successfully, but these errors were encountered: