Can shared structs store SharedArrayBuffer?

[Jamesernator]

So in the current proposal, shared structs can only have fields that are themselves primitives or other shared structs.

However SharedArrayBuffer feels like it should be sharable and is kind've important to be able to share as it the only mechanism through which Atomics instructions other than the four available to shared structs would be available. Of particular note is Atomics.wait and Atomics.notify which are important for implementing locks and such.

But currently SharedArrayBuffer probably couldn't be shared as it is an object, in fact the identity of the SharedArrayBuffer in general doesn't round trip as a new wrapper object is created everytime it's cloned.

Although having said that could we still set them anyway? There's a few possible strategies I could see:

• Respec SharedArrayBuffer to be a shared struct so that it can be shared like any other shared struct
  • This means the SharedArrayBuffer would be a frozen object, so this might not be web compatible
• Create wrappers when accessed on a shared struct, i.e. sharedStruct.someBuffer lazily creates a SharedArrayBuffer object wrapper when accessed
  • Two ways of doing this, either revive the same object identity each time, or everytime the field is accessed create a new object wrapper
• Add a new shared struct object that can be transformed to and from a SharedArrayBuffer
  • i.e. Something like const sabSharedRef = sab.toSharedArrayBufferRef() / const sab = sharedStruct.sabRef.toSharedArrayBuffer()

[syg]

It's a good point, and currently the answer is no. I haven't given it too much thought yet, but I agree we should do something here to be able to put SABs into shared structs. Do you think this is an important thing to have in the MVP?

An aside on locks: the explainer is terribly out of date and I haven't had the cycles to update. The current plan is to directly provide a Mutex and Condition instead of keep forcing folks to roll their own (which is hard to get right!).

[Jamesernator]

The current plan is to directly provide a Mutex and Condition instead of keep forcing folks to roll their own (which is hard to get right!).

Condition and Mutex pretty much cover all the uses I've personally had with SABs.

Do you think this is an important thing to have in the MVP?

I'm not sure, being able to share chunks of binary data feels like it should be something that is supported. Like I could imagine something like having some image data on a shared struct that is replaced every frame. But I haven't personally hit any use cases that wouldn't be covered by the additional primitives.

[germtb]

It would be valuable to add support for SharedArrayBuffer since one of the use cases would be to support parallel encryption which relies on bytes for keys and ciphertext. This would be valuable for any e2ee application (e.g. whatsapp web)

[xnimorz]

I'd also say, that SharedArrayBuffer is highly beneficial. It solves many issues as such:

1. Crypto keys sharing (as per @germtb point)
2. Media processing, incl video (e.g. when we have heavy processing moved to worker, but want result to be displayed on client, and shared canvas context might not help)
3. Any other binary formats