Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Set up test to reduce the amount of failed commits in ShadowTree (fac…
…ebook#38706) Summary: Pull Request resolved: facebook#38706 Fabric has a mechanism to resolve conflicts when there are race conditions committing new versions in different threads. This mechanism forces commits to be done in order, retrying commits when they didn't have time to finish before another concurrent commit. {F1061612667} This mechanism has an important drawback. If we have a continuous stream of short commits (e.g.: animations via Reanimated) and we want to do a large commit (e.g.: coming from React), the large commit could exhaust all attempts to finish and ultimately fail. Every time we tried to commit the large one, another small one would have had a chance to finish, forcing another retry. {F1061614717} In most of the cases where this happens, we didn't even need to fail the commits in the first place! **The only reason why we retry commits is so we make sure we are propagating the last state** (when state propagation is enabled in that commit). We don't reconcile the contents of the commits themselves (the tree we retry is exactly the same, if we exclude state). We can reduce the number of reconciliation failures (and completely remove them in the case of animations) if instead of checking if the base revision for a commit changed, we checked if the version of the state we propagated changed. We would have 3 scenarios when doing that: 1. Commit creating state vs. commit reusing state. If the commit creating the state went first, we would have to retry the commit reusing the state (to make sure we're reusing the new state). If the commit reusing the state went first, we wouldn't have conflicts, and we would just apply the new state on top of it. {F1061617730} 2. Commit reusing state vs. another commit reusing state. In this case the order doesn't matter and we don't need to trigger a conflict. Commits would be updated in the order in which they are applied. {F1061618406} 3. Commit creating state vs. commit creating state. In this case, we are not propagating state, so retrying the commits wouldn't do anything. We can ignore the conflicts in this case too. {F1061618689} Changelog: [internal] Reviewed By: sammy-SC Differential Revision: D47915384 fbshipit-source-id: bb4510c59bf32ca342c02f3bdb7029b545f56d99 Co-authored-by: Samuel Susla <samuel.susla@gmail.com> Co-authored-by: David Vacca Co-authored-by: Tomek Zawadzki <tomasz.zawadzki@swmansion.com> Co-authored-by: Krzysztof Piaskowy <krzysztof.piaskowy@swmansion.com>
- Loading branch information