Don't implement Send or Sync on Wasm#3691
Conversation
4549ddd to
1e99cd8
Compare
Send or Sync for Wasm typesSend or Sync on Wasm
1e99cd8 to
0edfbbe
Compare
|
@cwfitzgerald happy to rebase when this is ready to be merged, just hit me up. |
cwfitzgerald
left a comment
There was a problem hiding this comment.
I've had a comment queued up for the last 2 months....
The main change this needs is to have a feature to enable Send/Sync on wasm with a scary name like unsound_send_sync_threadless_wasm32 or something
688399a to
d50e308
Compare
It's quite a big change actually, I removed a lot of those |
d50e308 to
e894565
Compare
Just a suggestion, not less work, instead of a crate feature, we could just let Another one, we could do that this feature only work on Though the disadvantage is that some libraries might rely on this and wouldn't be compatible with atomics then. |
|
I added the crate feature. It's all very verbose and I should probably adjust the CI to cover it. But before I continue, WDYT @cwfitzgerald? |
|
I think this situation is fine, though I'm not sure the feature is technically unsound in this case, as you require atomics to have threads at all. I'm torn as I think we probably should make it unconditional on atomics, as if someone enables this feature, you get in that same "downstream someone breaks it", but maybe that's a good thing if it would lead to unsoundness. |
True, this isn't unsound then. Do you want me to rename the crate feature? EDIT: I'm gonna deal with CI and docs tmrw. |
|
Maybe rename it fragile instead of unsound. Thoughts? |
|
Yeah, that sounds fine! |
10b02e3 to
61decbf
Compare
|
I renamed the crate feature to |
|
I couldn't find a central place where all crate features were documented, would like some guidance on where to document this new crate feature. |
|
Rebased. |
cwfitzgerald
left a comment
There was a problem hiding this comment.
Thanks so much for the persistence on this!
|
Thanks for adding the |
|
I guess bevy would need bevyengine/bevy#6689 to support this properly. FYI |
Checklist
cargo clippy.RUSTFLAGS=--cfg=web_sys_unstable_apis cargo clippy --target wasm32-unknown-unknownif applicable.Connections
Fixes #2884.
Addresses #3026.
Description
Currently all types unsafely implement
SendandSyncon the Wasm target under the assumption that Wasm doesn't support multi-threading. Which it actually does (on nightly).This PR removes all these implementations and introduces
MaybeSendandMaybeSyncsupertraits to continue implementingSendandSyncon non-Wasm targets.Testing
It's not, maybe in the future we could add some Wasm multithreading examples/tests.