amethyst / legion_transform Goto Github PK

@AThilenius Are you on the Amethyst discord server? I've been trying to reach you there, but no one knows you there. I want to follow up on your comment in #3 (comment) about being so busy.

What are your long-term thoughts about maintainership of legion_transform? Amethyst has decided to depend on it, and there are active, ongoing changes in two different soft forks. There are likely to be a long tail of tweaks driven by Amethyst over the next weeks, months, and years.

Is this something you want to keep as an independent crate that you maintain personally? If so, would you consider granting write permissions to some key Amethyst developers so work can progress on this main repo even if you are busy? If you don't plan on maintaining this crate long term (as a maintainer myself, I wouldn't blame you), please let me know and we can discuss options. Also, I'm happy to chat or voice-chat on the Amethyst Discord server if that's more convenient. My username is also @CleanCut there.

Update: There is also been a suggestion floating around to move this to amethyst/legion_transform. We're waiting to hear your thoughts.

/cc @Jojolepro @chemicstry

Right now trying to rebuild the forest of transform updates panics because components in the same world are accessed mutably on separate threads:

thread '<unnamed>thread '' panicked at '<unnamed>called `Result::unwrap()` on an `Err` value: "resource already borrowed as mutable"' panicked at '', called `Result::unwrap()` on an `Err` value: "resource already borrowed as mutable"src\libcore\result.rs:999:5'

A single Transform component is only every accessed by a single thread, but obviously Legion has no way of knowing that (and I'm not familiar enough with Legion to even know if that matters). Need a way to work around that, preferably without any/much overhead, probably an unsafe block and raw pointers.

@TomGillen any recommendations?

Justification for multi-threading

Actually building the forest of independent hierarchical transform updates isn't worth multi-threading. Most of the performance hit comes from cache thrashing, and the per-task workload is very small. Additionally the mutex contention would be significant.

However, once the forest is built, it is trivially parallelizable as it's an independent forest of trees (DAG with single-parent nodes). There is no thread contention and the CPU workload here could be significant for large tree updates.