Skip to content
New issue

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

Remove Sync bound on Component and Resource (adopted) #5879

Closed

Conversation

JohnTheCoolingFan
Copy link
Contributor

Adoption of #4680

Objective

Fixes #2487. Remove the Sync bound on Component and Resource to allow Send-only components.

Solution

  • Remove Sync bound from Component and Resource.
  • Address the compilation errors.
  • Changed the PhantomData<T> in FetchState and SystemParamState to use PhantomData<fn() -> T> to ensure they're Sync.
  • Add a compile_fail_test.
  • Add Sync bound on the WorldQuery impl for &T.
  • Add Sync bound on Res<T> and Option<Res<T>>
  • Add Sync bound on Query::get_component, World::get, EntityRef::get, and EntityMut::get.

Changelog

Removed: Sync bound on Component and Resource.

Migration Guide

Component and Resource no longer requires Sync. Any generic code using Component as a bound, &T as Query parameter, or Res<T> might require an additional Sync bound.

@JohnTheCoolingFan
Copy link
Contributor Author

Currently working on resolving merge conflicts

@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use labels Sep 4, 2022
@alice-i-cecile
Copy link
Member

Sounds good :) Let us know if you have any questions or need help.

@@ -25,7 +25,7 @@ use std::fmt::Debug;
use super::IntoSystemDescriptor;

/// A type that can run as a step of a [`Schedule`](super::Schedule).
pub trait Stage: Downcast + Send + Sync {
pub trait Stage: Downcast + Send {
Copy link
Contributor

@bjorn3 bjorn3 Sep 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't schedule.get_stage() depend on stages being Sync?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for .iter_stages().

@@ -1385,7 +1402,7 @@ impl World {
#[inline]
pub fn get_resource_by_id(&self, component_id: ComponentId) -> Option<Ptr<'_>> {
let info = self.components.get_info(component_id)?;
if !info.is_send_and_sync() {
if !info.is_send() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should check for sync, right?

@JohnTheCoolingFan
Copy link
Contributor Author

Currently can't figure out how to make impl WorldQuery for &mut T for !Sync T

Comment on lines +280 to +283
/// Non-`Sync` components are supported, but cannot be accessed as `&T`,
/// as the type cannot be safely read from multiple threads at the same
/// time. These components must be accessed via a `&mut T` to guarentee
/// that the system has exclusive access to the components.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this isnt going to work and imo is flawed anyway, why shouldn't you be able to use &T from multiple places in a system?
imo we should do one of:

  • Add NonSync versions of &T and &mut T, leaving the existing types requiring T: Sync
  • Remove T: Sync bound from &T and &mut T worldqueries (this is a bad idea since now we're going to be registering almost eveyr component as !Sync)
  • Add a NonSync<T> and use that as the readonly version of &mut T (this is a bad idea since its going to screw up the Query::to_readonly effort by making the readonly version of Query<&mut T> not be Query<&T>)

I am assuming here that the scheduler is smart enough to know not to schedule two systems with read only access of a !Sync component in parallel, if not that should be fixed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just add NonSyncRead<T> for the 'use &T from multiple places in a system' case?

Fundamentally, &mut T requiring T: Sync is entirely superfluous - the requirement that T is Sync would never be used.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, because we need to convert to readonly. That's annoying.
I don't suppose we can gate a readonly conversion existing on T being Sync? Is conversion to readonly really a fundamental part of the Query API?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

conversion to readonly doesnt require it. we could after all set the readonly version of &mut T to be NonSync<T>. It's just kinda silly to have the readonly version of &mut T not be &T.

Is conversion to readonly really a fundamental part of the Query API?

I think so? It's not quite there yet but I hope that in a bit of time we'll have much more flexibility around changing the Q/F generics and being able to downgrade a query to readonly is a part of that. Personally I value to_readonly working on everything a lot more than some extreme edge case of non sync components needing to use NonSyncMut<T> instead of &mut T

@BoxyUwU
Copy link
Member

BoxyUwU commented Oct 17, 2022

@JohnTheCoolingFan are you still working on this? I'd like to get !Send !Sync components implemented to make World: !Send + !Sync a more usable option for solving some other bevy issues

@JohnTheCoolingFan
Copy link
Contributor Author

JohnTheCoolingFan commented Oct 17, 2022

No, I just resolved the merge conflicts in an attempt to bring some attention and possibly merge. I now realise that I do not have the knowledge and skills to further maintain this PR.
@BoxyUwU

@alice-i-cecile alice-i-cecile added the S-Adopt-Me The original PR author has no intent to complete this work. Pick me up! label Oct 17, 2022
@BoxyUwU
Copy link
Member

BoxyUwU commented Oct 18, 2022

I'll make a PR for this then 👍

@BoxyUwU BoxyUwU removed the S-Adopt-Me The original PR author has no intent to complete this work. Pick me up! label Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events C-Usability A targeted quality-of-life change that makes Bevy easier to use
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Component: Sync (might be) too strict.
6 participants