mirror of
https://github.com/flatpak/flatpak.git
synced 2026-03-17 06:29:21 -04:00
c48d8f427f
This is taken in exclusive mode whenever we prune the repo. Anything that is not protected against object disappearing from the repo can take the lock in a shared mode to avoid running at the same time as a prune operation. The two operations the are problematic in this respect is Pull: * During the pull we see that some object we require is already available and doesn't need downloading. We can't have it be removed before we commit the transaction. * During the transaction commit we're moving the object to the repo, and they risk being pruned as unreachable until we have updated the ref. Deploy: * Once we start checking out a particular ref we assume all the object from it is reachable. If the ref is updated in parallel some object can become unreachable and removed. So, we take shared locks in these operations. In the prune operation we take the block non-blocking, and skip the prune entirely if some other operation is outstanding, because we don't want to block a long time, and its likely that due to the other operation we will run prune shortly anyway. Note: Nothing protects the system-helper case when we download to a separate repo. However, if there is a race we will get an error when importing this to the system repo, so we'll never end up in an inconsistent state.