Should wgpu types implement Send / Sync?

[Pauan]

Right now pretty much all wgpu types implement both Send and Sync.

However, it has not been decided yet whether WebGPU will support multi-threading or not.

And even if it does support multi-threading, it has not been decided which types are thread-safe and which are not:

gpuweb/gpuweb#354

That discussion uses web terminology, here is the Rust equivalent:

• "serializable" means the same behavior as Arc: the object is Clone + Send + Sync, it doesn't copy the data, it just sends the pointer to the other thread. And multiple threads can access the same object at the same time, so it is fully thread-safe and synchronized.

• "transferable" means Send + !Sync, which means you can send the object to another thread, but you can't access it from multiple threads at the same time.

• If an object is not "serializable" or "transferable" then that means !Send + !Sync (single-threaded only).

Note that the web semantics does matter for wgpu, because you can compile wgpu to Wasm + WebGPU, and Wasm can run on multiple threads in the browser. So wgpu has to match the multi-threaded behavior of the web.

Device will likely be Send + Sync, and other resources (like Buffer) will likely be Send + Sync as well, but that hasn't been decided yet.

If the wgpu types implement Send + Sync, then it is a breaking change to make them Send + !Sync in the future.

However, if the wgpu types implement Send + !Sync, then they can be changed to Send + Sync later without a breaking change.

At the very least, the CommandEncoder, ComputePassEncoder, and RenderPassEncoder types (and associated types like RenderPass) should be !Send + !Sync since they will likely never be thread safe.

[Pauan]

From that discussion, I think there's a very high chance that most things will be Send + Sync, so the only real change that needs to happen is to make the *Encoder types !Send + !Sync.

[daxpedda]

I believe #3691 made everything on Web !Send + !Sync.
So this shouldn't be a problem until things change.

[Pauan]

FWIW, I believe we are still pretty far away from actually Send/Sync in Wasm. We would need the TC39 structs proposal, which would first need to trickle down the whole tech-stack before it reaches us here in Wgpu.

I don't think TC39 structs are relevant, since they don't solve the problem of needing to use postMessage.

The WebGPU types are already serializable (at least in theory), so they already behave like TC39 structs. You can send WebGPU types to other workers, you just have to use postMessage to do so.

The explainer gives some potential solutions that don't require postMessage.

[Pauan]

Also, it's still possible for the user to asynchronously share WebGPU types by manually using postMessage.

So we could have an API design like this:

// The to_js method converts the wgpu type into a JsValue which can be shared between workers by using postMessage
buffer.to_js()

// The try_from method attempts to convert the JsValue back into a wgpu type
Buffer::try_from(&js)

So that way users can call to_js() on the wgpu type, then use postMessage to send the JS value to another worker, and then use try_from to recreate the wgpu type from the JS value.

This is extra work for the user, but it would enable sharing wgpu types (at least with the WebGPU backend).

[cwfitzgerald]

The WebGPU multi-threading explainer talk about accessing WebGPU types across Wasm threads:

That is true, I just am not holding my breath on any way for that to actually occur. All of the existing solutions have some downsides which will need to be debated in the webgpu group.

Why is that? Having feature parity between all of the backends and platforms is clearly a good thing, since portability is one of wgpu's major strengths.

To be clear, I'm not saying we 100% shouldn't do this or anything. Mainly it's a lot more code to maintain and we try to stay away from these heavy handed polyfills, so the user gets exactly what they expect to happen.

This is extra work for the user, but it would enable sharing wgpu types (at least with the WebGPU backend).

This is the api I was expecting us to expose, at least in the medium term.

[daxpedda]

FWIW, I believe we are still pretty far away from actually Send/Sync in Wasm. We would need the TC39 structs proposal, which would first need to trickle down the whole tech-stack before it reaches us here in Wgpu.

I don't think TC39 structs are relevant, since they don't solve the problem of needing to use postMessage.

Please correct me if I'm wrong, but the idea here is that TC39 structs should pave the way for either:

1. Allowing a storage space to store shared structs, which then could be passed around to every Web worker through postMessage(). This system could e.g. be used in the future by wasm-bindgen to allow for Send/Sync types.
2. Allow something like the Wasm thread spawn proposal to use it in a more "integrated" way by decoupling Wasm multi-threading from Web workers. Ergo we won't have a Wasm instance per Web worker anymore.

[Pauan]

Allowing a storage space to store shared structs, which then could be passed around to every Web worker through postMessage(). This system could e.g. be used in the future by wasm-bindgen to allow for Send/Sync types.

I think it depends on whether we can implement dynamic collections with them or not. Right now they only have a fixed-size SharedFixedArray, which limits how many objects you can share between threads.

So the TC39 struct proposal might not be enough to implement Send / Sync.

Allow something like the Wasm thread spawn proposal to use it in a more "integrated" way by decoupling Wasm multi-threading from Web workers. Ergo we won't have a Wasm instance per Web worker anymore.

Wasm threads don't change anything with regard to Send / Sync, the behavior is the same regardless of whether it's 1 Wasm instance or multiple Wasm instances

The fundamental issue is that we need a way to synchronously send a JS object from one worker/thread to another worker thread (i.e. not using postMessage).