We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Worley noise (and some other functions) contain custom Rc<Fn> distance functions.
Rc<Fn>
Usage of Rc makes these types non-Send, which makes it difficult to use in many ECS implementations
Would it be possible to change the type to Arc or possibly introduce a generic with a default value to get around these limitations?
error[E0277]: `Rc<(dyn for<'a, 'b> std::ops::Fn(&'a [f64], &'b [f64]) -> f64 + 'static)>` cannot be shared between threads safely --> shared/src/entities/enemy_controller.rs:150:17 | 150 | idle_state: IdleState, | ^^^^^^^^^ `Rc<(dyn for<'a, 'b> std::ops::Fn(&'a [f64], &'b [f64]) -> f64 + 'static)>` cannot be shared between threads safely | = help: within `IdleState`, the trait `Sync` is not implemented for `Rc<(dyn for<'a, 'b> std::ops::Fn(&'a [f64], &'b [f64]) -> f64 + 'static)>`, which is required by `IdleState: ComponentValue` note: required because it appears within the type `Worley` --> /home/freja/.cargo/registry/src/index.crates.io-6f17d22bba15001f/noise-0.9.0/src/noise_fns/generators/worley.rs:11:12 | 11 | pub struct Worley {
From looking at the code, a non-Send distance function is not required, as the provided distance functions are purely "math" and thus could be send.
Thanks
The text was updated successfully, but these errors were encountered:
No branches or pull requests
Worley noise (and some other functions) contain custom
Rc<Fn>
distance functions.Usage of Rc makes these types non-Send, which makes it difficult to use in many ECS implementations
Would it be possible to change the type to Arc or possibly introduce a generic with a default value to get around these limitations?
From looking at the code, a non-Send distance function is not required, as the provided distance functions are purely "math" and thus could be send.
Thanks
The text was updated successfully, but these errors were encountered: