Allow NonSend components

[alice-i-cecile]

What problem does this solve or what need does it fill?

Allow data that is not Send to be stored in components, increasing API flexibility.

This is particularly useful for structs that contain a Cell or similar, allowing for interior (within-system) parallelization.

What solution would you like?

Mirror / share the NonSend resource API. Systems that have at least one NonSend component or resource access can only run on the main thread to ensure that the data does not have to be passed between threads.

Reusing NonSend for both resources and components would be the best naming scheme for this if possible.

What alternative(s) have you considered?

Store a reference to a NonSend resource maybe? Just Don't Do That.

Additional context

This will impact the Component trait (#1843), as it will not include Send + Sync trait bounds. Instead, those will be limited to using components in a parallelizable fashion.

[Ratysz]

Systems executor relies on this method (looks like it's better-documented on the main branch?) to know if it has to schedule the system on the main thread. It simply reads SystemMeta::is_send, which is set in SystemParamState::init(). Should be plug-and-play.

[james7132]

Closing this for the same reasons as #1719 and #4247. Supporting !Send resources and components has serious soundness issues with World: Send + Sync and has scheduling issues.

For more context, please see this discussion on Discord: https://discord.com/channels/691052431525675048/692572690833473578/1047997793375096852, and #6552.

[mrchantey]

I'd like to reopen this issue with an alternative approach, or rather only the SystemMeta::is_send component of this proposal.

The SendWrapper Pattern

NonSend types can be made Send with unsafe, and used safely so long as they are only accessed from the originating thread. This pattern is already possible in bevy but easy to mess up. Exposing is_send on the component trait would make the pattern safe by default.

Current approach

#[derive(Component)]
struct MyComponent<T>(send_wrapper::SendWrapper<T>);

fn system(
  // adding a NonSend parameter to mark the system as NonSend
  _: NonSendMarker,
  query: Query<&MyComponent<RefCell<i32>>>
) {
  let value = *query.single().unwrap().0.borrow();
}

Proposal

#[derive(Component)]
#[component(non_send)]
struct MyComponent<T>(send_wrapper::SendWrapper<T>);

// NonSend system is inferred by a query with NonSend components
fn system(
  query: Query<&MyComponent<RefCell<i32>>>
) {
  let value = *query.single().unwrap().0.borrow();
}

Notes

• we're already using SendWrapper within the WgpuWrapper
• This approach is incompatible with one of the goals of Take non-Send resources out of World #9122, dropping the World from a different thread, which would cause SendWrapper to panic.

[mrchantey]

Ok turns out the SendWrapper pattern is not such a clean solution, marking the SystemParam as !Send doesn't stop a user from adding or removing a !Send component from a Send system.

As far as footguns go its a very simple fix, just by adding NonSendMarker whenever one of these systems panics, and its better than some kind of !Send HashMap for my use-case, but I no longer think we should make changes to the engine to accomodate this pattern.