Add Sync trait on structs used in globals#65
Conversation
|
This is incomplete, it only solves part of the problem. In Rust, This PR solved the problem for One solution would be to translate the const global variables as None of the two above solution is complete. For the moment we can translate all global variables as This only touches the unsafe model. |
This is a continuation of #65: > This is incomplete, it only solves part of the problem. > > In Rust, `static` global variables require `Sync` so that multiple threads can take an immutable reference to the `static` storage, `static mut` global variables don't require `Sync` because it's by itself unsafe to access the `static mut` storage. > > This PR solved the problem for `static` global struct objects that contained raw pointers. Raw pointers are not `Sync` in Rust so any struct containing them needs to implement the `Sync` trait. What this PR does not solve is global arrays containing pointers in `static` storage, for example `[*const T; N]`. > > One solution would be to translate the const global variables as `const` instead of `static`. However `const` global variables don't have a stable address in the final binary. Other solution would be to wrap the array in a newtype, but this makes later usages of the array harder in the codegen. > > None of the two above solution is complete. For the moment we can translate all global variables as `static mut` instead of `static` so that we don't have to implement `Sync` for them. By construction, the generated code is guaranteed not to modify the global variable, even if it's declared as `static mut` instead of `static`. > > This only touches the unsafe model.
To compile structs used in globals that contain raw pointers, we need to add the Sync marker trait.