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

[Merged by Bors] - Remove Sync bound from Command #5871

Closed
wants to merge 1 commit into from

Conversation

Demiu
Copy link
Contributor

@Demiu Demiu commented Sep 3, 2022

Unless I'm mistaken it is unnecessary, Commands are never accessed from two threads simultaneously. It unnecessarily restricts Command structs

@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 3, 2022
Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

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

It compiles! This lines up with my mental model of commands: they're dispatched across threads to various systems and collected back from them (and so need a Send bound), but there's no time where a Sync bound would be required.

@DJMcNab if you're in agreement I'm happy to merge this right away.

@DJMcNab
Copy link
Member

DJMcNab commented Sep 3, 2022

I'd need to do an audit of CommandQueue to be sure.

iirc it unsafely implements Send and Sync, referencing this impl? I think SystemParam's state need to be Send/Sync, so this compiling seems suspect to me without any actual checks.

For example, this compiling without the Send bound would definitely be wrong, but I somewhat suspect it might do. We probably should have a safety comment here that that supertrait is required for soundness.

Also, I thought there was already another pr which did this, although I don't have a reference to hand. It might have started, but the plumbing required to actually do it correctly overwhelmed the author - not sure?

Always happy to tidy up our send/sync requirements, but I need to check this is actually correct.

@alice-i-cecile
Copy link
Member

Also, I thought there was already another pr which did this, although I don't have a reference to hand. It might have started, but the plumbing required to actually do it correctly overwhelmed the author - not sure?

A quick skim of the PRs didn't show anything for me, and I don't remember this.

It appears that the SAFETY comments of CommandQueue here are still valid: https://github.com/bevyengine/bevy/blob/d38a8dfdd79f6fd8e1e915aa5e2ddb03ffdaa76a/crates/bevy_ecs/src/system/commands/command_queue.rs

Definitely needs a close look though.

@Demiu
Copy link
Contributor Author

Demiu commented Sep 3, 2022

I did look into this beforehand and didn't just remove Sync.
The CommandQueue doesn't make it's contents pub and the only 2 associated functions it has take mutable reference, so I do not think there is a way to mutate anything behind a shared reference to a queue. CommandQueue::apply just goes through commands in a queue sequentially on a single thread. Edit: A Command can't be run on two threads simultaneously because the only function it has a) takes &mut World b) consumes self.
Yes, you technically can also remove Send bound on Command, which is wrong, but it will still compile because CommandQueue erases the type of a command and stores them as just bytes.
And since this type erasure happens the unsafe impls for Send and Sync on CommandQueue are superfluous because to the compiler all of it's elements are Send + Sync.

Copy link
Member

@JoJoJet JoJoJet left a comment

Choose a reason for hiding this comment

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

I like it

@alice-i-cecile alice-i-cecile added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Sep 22, 2022
Copy link
Member

@cart cart left a comment

Choose a reason for hiding this comment

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

Yeah this aligns with my view of the world

@cart
Copy link
Member

cart commented Sep 27, 2022

bors r+

bors bot pushed a commit that referenced this pull request Sep 27, 2022
Unless I'm mistaken it is unnecessary, Commands are never accessed from two threads simultaneously. It unnecessarily restricts Command structs
@bors bors bot changed the title Remove Sync bound from Command [Merged by Bors] - Remove Sync bound from Command Sep 27, 2022
@bors bors bot closed this Sep 27, 2022
james7132 pushed a commit to james7132/bevy that referenced this pull request Oct 19, 2022
Unless I'm mistaken it is unnecessary, Commands are never accessed from two threads simultaneously. It unnecessarily restricts Command structs
james7132 pushed a commit to james7132/bevy that referenced this pull request Oct 28, 2022
Unless I'm mistaken it is unnecessary, Commands are never accessed from two threads simultaneously. It unnecessarily restricts Command structs
ItsDoot pushed a commit to ItsDoot/bevy that referenced this pull request Feb 1, 2023
Unless I'm mistaken it is unnecessary, Commands are never accessed from two threads simultaneously. It unnecessarily restricts Command structs
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 S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants