You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've been recently looking in depth at what Metal/Cocoa objects are Send+Sync in gfx-rs/metal-rs#40. Our D3D12 backend in gfx-rs has a similar issue: a lot of unsafe impl Send/Sync for structures containing ComPtr.
What can be said about COM guarantees of thread safety?
This question also touches the problem that all ComPtr wrapped methods are &mut self, which automatically forbids any sharing (in safe code), even though we have examples (e.g. ID3D12Device) that are documented as thread-safe.
The text was updated successfully, but these errors were encountered:
In winapi 0.3 all interfaces take &self for their methods, not &mut self. As discussed in IRC quite a bit, COM thread safety is incredibly thorny due to some interfaces being thread safe and some not, as well as thread safety depending how the thread the object was created on was initialized for COM, and whether the thread you are sending the object to was initialized for COM in the right way as well. Since I can make zero guarantees about whether an arbitrary interface is thread safe, I cannot correctly impl Send or Sync for ComPtr.
We've been recently looking in depth at what Metal/Cocoa objects are Send+Sync in gfx-rs/metal-rs#40. Our D3D12 backend in gfx-rs has a similar issue: a lot of
unsafe impl Send/Sync
for structures containingComPtr
.What can be said about COM guarantees of thread safety?
This question also touches the problem that all
ComPtr
wrapped methods are&mut self
, which automatically forbids any sharing (in safe code), even though we have examples (e.g.ID3D12Device
) that are documented as thread-safe.The text was updated successfully, but these errors were encountered: