Multithreading: Support in structuredClone() / transferable / serializable objects?

[leebyron]

Has much thought been put into how R/T/B are transferred across agent boundaries?

I envision one of R/T's long term benefits to be unlocking multithreaded programming models for JavaScript. Today the closest we have for this are "agent clusters" and web workers with SharedArrayBuffers, however this can be very limiting when the rest of the language semantics don't operate on memory buffers. Since R/T are immutable they could provide a way to efficiently share memory and data across agents/workers in O(1) while still using high level language features.

The structuredClone() algorithm is used for postMessage and other web-level transferring and serialization, but I am no expert on the whatwg specs. I'd love thoughts on this.

Importantly, I think our "Box" type must also be transferable (serializable?) such that sending a Box of an Object across an agent boundary and back again should still resolve to the same original object (and preserve === with a Box that was not sent over) for example:

const data = #{ node: Box(document.body) }
// Identity API - sends what it receives:
window.addEventListener("message", event => {
  assert(event.data === data)
  assert(event.data.node === data.node)
  assert(Box.unbox(event.data.node) === document.body)
});
otherAgent.postMessage(data)

[mhofman]

I honestly doubt R/T would be optimized to that extent for a while. It seems that engines aren't even sure they'll be able to efficiently rope them at first.

Regarding the round tripping of Boxes to other agents through structured cloning, I actually had an idea for a similar concept a few years ago (in the form of a special Tag object). However given that even symbols can't be sent over postMessage currently (or for that matter anything that holds an identity), I'm also doubtful this will be considered. With roundtrip-able identities, you'd open yourself to all kinds of distributed garbage collection craziness (which I have an idea on how to solve, but that's definitely for later).

You best bet regarding structured data shared across agents is to get involved in @syg's Shared Structs proposal.

[Jack-Works]

It can be shared across agents but not by transferring, after you transfer this item, it no longer is available in the original agent.

[nicolo-ribaudo]

I think this would be done in a follow-on proposal to the WHATWG spec. The default behavior of structuredClone is to recursively clone its argument, so structuredClone(Box({ x: 1 }) should return Box(structuredClone({ x: 1 }). However, it can be easily* extended to support something like

let o = {};
structuredClone(Box(o), { transfer: [Box(o)] }) === Box(o)

which doesn't recursively clone boxes but copies them as-is (leaving the associated realm for possible realm checks the same)

* easy from a spec point of view; hard from an implementation point of view because of the GC problems that @mhofman mentioned.

[mhofman]

I would honestly prefer to exclude Box() in structured clone for now, the same way symbols are excluded. Automatically unboxing them seem like a departure from virtualizability, and the model that you need access to Box.unbox to open a box. While it doesn't allow you to observe the identity of the content, it does allow to observe the structure of the content.

[Jack-Works]

structured clone of ECMAScript built-in values is going to move into the ECMAScript spec (tc39/ecma262#2555)

[mhofman]

structured clone of ECMAScript built-in values is going to move into the ECMAScript spec

I'm not sure how that has any implications.

[rricard]

Box is not part of the proposal anymore (Symbols as WeakMap keys instead).

Like strings, Record & Tuple are defined as serialisable as long as their contents are serialisable: there is a possibility that engines could "share" strings across workers in a non-observable way. The same could be considered with Record & Tuple but up to the engines to implement.

Additionally work on structuredClone has started here: whatwg/html#6958