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

Track component changes like resource changes #116

Merged
merged 2 commits into from Mar 28, 2020

Conversation

Guvante
Copy link
Contributor

@Guvante Guvante commented Mar 8, 2020

  • Track reads as well as writes
  • Writes are dependent on reads to avoid simultanious execution
  • Reads handled after writes to prevent overriting last read

@Guvante
Copy link
Contributor Author

Guvante commented Mar 8, 2020

Mostly stole the way it was being done for resources. I think revisiting whether read and write for components is good is worthwhile but figured a bug fix that didn't require deciding on that was good.

@TimonPost
Copy link
Member

Great! I tried your branch and it seems to fix #114,

  • @jaynus (was this the area that you were talking about?)

@jaynus
Copy link
Contributor

jaynus commented Mar 9, 2020

@TimonPost yep, this would be where we missed a check. Makes sense, I oopsied.

@Guvante can you add Timon's example in #114 as a test in here so we can have a regression test?

@TimonPost
Copy link
Member

TimonPost commented Mar 9, 2020

@jaynus I just tried those changes in my own project but still get the same error. Playing with system order doesn't matter. I try to reproduce this with the mini-example again. It does not occur there. Strange ...

@TimonPost
Copy link
Member

TimonPost commented Mar 9, 2020

I might have found an issue in my code. So wait before putting in more research time.

@TimonPost
Copy link
Member

It happens when I add .write_component::<UidComponent>() to a system. A lot of my systems query with read access to this component. There is only one system that uses this component to write to.

My guess would be that this system with write access is qued in parallel with the systems using it in there read query. Which will result in this type being borrowed immutable.

@TomGillen
Copy link
Collaborator

I am not sure what is wrong with CI at the moment, it seems to be having trouble checking out the repo. I have ran the CI tests locally though and they all pass.

@Guvante
Copy link
Contributor Author

Guvante commented Mar 9, 2020

Hmm, it looks like legion_systems::system::par_comp_readwrite should be triggering this same bug but it doesn't seem to be. The computed dependencies are 3 requires 2, 4 and 5 require both 2 and 3. In theory that should trigger the same bug as TestSystem1 can run with anything and TestSystem4 and TestSystem5 can run in parallel.

EDIT: I feel silly. The test inserts Pos and Vel and then iterates on components custom to the test. Thus it doesn't actually grab anything at run time. Changing the references to the custom components causes the test to fail in the same way. Even my changes aren't enough to get the updated version to pass so going to look at fixing that test instead of adding a new one.

- Track reads as well as writes
- Writes are dependent on reads to avoid simultanious execution
- Reads handled after writes to prevent overriting last read
@Guvante
Copy link
Contributor Author

Guvante commented Mar 17, 2020

The tests now pass so this should be good to go.

@TomGillen TomGillen merged commit eabe6df into amethyst:master Mar 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants