-
Notifications
You must be signed in to change notification settings - Fork 56
Thread Safety #184
Copy link
Copy link
Closed
Labels
has resolutionIssue is resolved, just needs to be doneIssue is resolved, just needs to be donethreadingThread safety and WASM-JS threading problemsThread safety and WASM-JS threading problems
Metadata
Metadata
Assignees
Labels
has resolutionIssue is resolved, just needs to be doneIssue is resolved, just needs to be donethreadingThread safety and WASM-JS threading problemsThread safety and WASM-JS threading problems
This thread is for figuring out what operations are thread-safe (internally synchronized). Last weeek's webgpu.h meeting ended up discussing this as an offshoot of #9 because of the question of whether device.destroy() must be externally synchronized with encoding (i.e. a multithreaded application must add its own locks).
wgpu in safe Rust wouldn't allow this kind of unsafety, so it's more of a question of whether dawn and wgpu-core would have (unsafe) encoder methods that require external synchronization, perhaps alongside safe versions. In the safe version, each individual encoder command has to take a read-lock on the device's read-write-lock, or we would need something else clever, like a way for the entire encoder to take a lock until it's finished or dropped, without making it impossible to ever actually destroy a device.
I think we agreed to just go ahead with making these internally synchronized. Maybe in the future if we can't come up with something better and consider adding unsafe versions of encoder commands?