Some Win32 interfaces should be marked with an agile attribute #740
Comments
mikebattista
added
the
usability
|
How can I tell which interfaces should be marked agile? Also, is there an attribute I can use to indicate it's agile, or would I need to make one? |
|
I think we'll need to mark them manually. Maybe something like "everything in d3d12.h should be agile"? |
|
Any progress on this? We have more customer interest to resolve this here: microsoft/windows-rs#1519 |
Are we safe making that assumption, that all interfaces in d3d12.h are agile? What about the other d3d headers? Can we make the same assumption for those? |
|
Any d3d* header is definitely agile - these are all Nano-COM interfaces. |
…on` and `MemoryBlock` Thanks to windows-rs implementing these unsafe markers for COM objects because they are [declared `agile`] (and wrapping the raw pointers in the first place, which are not marked `Send`/`Sync` by the Rust language) we can now let the compiler auto-implement the marker traits. This'll benefit safety (the traits require `unsafe` for a reason) in case we add fields to these structs that aren't `Send`/`Sync` in the future. The same should be done for Vulkan at some point, by manually defining `Send`+`Sync` wrapper types around affected fields. Also clear out `MemoryType`'s `Debug` implementation which is already implemented by windows-rs. [declared `agile`]: microsoft/win32metadata#740
…on` and `MemoryBlock` (#152) Thanks to windows-rs implementing these unsafe markers for COM objects because they are [declared `agile`] (and wrapping the raw pointers in the first place, which are not marked `Send`/`Sync` by the Rust language) we can now let the compiler auto-implement the marker traits. This'll benefit safety (the traits require `unsafe` for a reason) in case we add fields to these structs that aren't `Send`/`Sync` in the future. The same should be done for Vulkan at some point, by manually defining `Send`+`Sync` wrapper types around affected fields. Also clear out `MemoryType`'s `Debug` implementation which is already implemented by windows-rs. [declared `agile`]: microsoft/win32metadata#740
Fixes microsoft#1588 Just like microsoft#740/microsoft#861 the `IDXGI*` interface classes should be marked as `Agile` so that `windows-rs` implements `Sync` and `Send` marker `trait`s for these `struct`s in Rust, allowing these types to be fearlessly shared across threads, and accessed from multiple threads at once: their implementations [are thread-safe]. [are thread-safe]: microsoft#1588 (comment)
* Mark `IDXGI*` interfaces as `[Agile]` Fixes #1588 Just like #740/#861 the `IDXGI*` interface classes should be marked as `Agile` so that `windows-rs` implements `Sync` and `Send` marker `trait`s for these `struct`s in Rust, allowing these types to be fearlessly shared across threads, and accessed from multiple threads at once: their implementations [are thread-safe]. [are thread-safe]: #1588 (comment) * Updated the baseline. --------- Co-authored-by: Mike Battista <[email protected]>
|
I'm having a hard time finding information on what this |
|
@marler8997 In this case, it denotes the backing Direct3D 12 objects can be used from any apartment/thread. You're not limited to the apartment/thread that created the object. This information is used by projections, such as Rust, to light up async capabilities. Does that help at all? |
|
Yeah thanks for the explanation. |
For example, the various DirectX interfaces (the "nano-COM" ones) should all be marked as agile. This would allow the rust projection to mark them as implementing the Send and Sync traits.
The text was updated successfully, but these errors were encountered: