-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Remove Sync bound on Component and Resource (adopted) #5879
Conversation
Currently working on resolving merge conflicts |
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 { |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
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?
Currently can't figure out how to make |
/// 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. |
There was a problem hiding this comment.
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 requiringT: 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 theQuery::to_readonly
effort by making the readonly version ofQuery<&mut T>
not beQuery<&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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
@JohnTheCoolingFan are you still working on this? I'd like to get |
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. |
I'll make a PR for this then 👍 |
Adoption of #4680
Objective
Fixes #2487. Remove the
Sync
bound onComponent
andResource
to allow Send-only components.Solution
Sync
bound fromComponent
andResource
.PhantomData<T>
inFetchState
andSystemParamState
to usePhantomData<fn() -> T>
to ensure they'reSync
.compile_fail_test
.Sync
bound on theWorldQuery
impl for&T
.Sync
bound onRes<T>
andOption<Res<T>>
Sync
bound onQuery::get_component
,World::get
,EntityRef::get
, andEntityMut::get
.Changelog
Removed:
Sync
bound onComponent
andResource
.Migration Guide
Component
andResource
no longer requiresSync
. Any generic code usingComponent
as a bound,&T
as Query parameter, orRes<T>
might require an additionalSync
bound.