Support !Send + !Sync Resources

[farnoy]

Hi,

I have a type that's neither Send nor Sync and I can't find a way to use this data as part of the Schedule. Resources, System and IntoThreadLocalSystem all have requirements on Send + Sync. Would it be possible to relax this?

[cart]

Supporting !Send + !Sync resources is definitely a common enough requirement that we should support it. We've already had folks hit this in a number of places and working around it results in ugly and/or unsafe/incorrect code.

[Waridley]

Could this also apply to Components? E.g. I have a component that's Send but !Sync, but I only access it in one system, so wrapping it in a Mutex is pointless. However, I don't know if there's any way to enforce in the AppBuilder that I'm only using it in one system when it's !Sync.

[Waridley]

Also, this will come up for web support, because WinitWindows are !Send + !Sync on WASM.

[kakoeimon]

Where is the problem with Mutex or RWLock?
About components keep in mind that send and sync are requirements of hecs.

[cart]

Mutex<T> and RWLock<T> both require T to be Send. Additionally, some resource/component types might only work correctly when they have been accessed from the main thread. i think we should try to honor the Send/Sync semantics, otherwise we might encounter undefined behavior.

Adding !Send + !Sync resources should be relatively straightforward. Supporting !Send + !Sync components will be a bit harder, but I'm 100% ok with modifying hecs to support this.

[Waridley]

I suppose wrapping a Send + !Sync component in a Mutex is probably not a big deal if I'm only using it in one system, since the lock should basically always succeed, costing only a couple atomic operations... Still a slight waste, but the bigger issue is probably !Send resources.

[kakoeimon]

I don't think this is a requirement. I mean you can use send + sync in wasm as long you do not create any threads.
For example I have used hecs with Mutex for wasm.

[smokku]

Faking it does work in a single threaded wasm runtime:

bevy/crates/bevy_winit/src/winit_windows.rs

Line 111 in 34c6f5f

unsafe impl Send for WinitWindows {}

[chemicstry]

Supporting threads in wasm is a hard requirement IMO. This can work for the time being, but I'm sure other use cases for !Send will pop up.

I would also caution against bare unsafe impl Send and at least use a wrapper type which checks thread id before accessing like the one Amethyst uses. That way you at least get a panic instead of undefined behavior.

[Waridley]

Yeah, the godot-rust bindings do something similar with LocalCellData which panics if the thread ID is not the same