Module cargo::util::cache_lock
source · Expand description
Support for locking the package and index caches.
This implements locking on the package and index caches (source files,
.crate
files, and index caches) to coordinate when multiple cargos are
running at the same time.
§Usage
There is a global CacheLocker
held inside cargo’s venerable
GlobalContext
. The CacheLocker
manages creating and tracking the locks
being held. There are methods on GlobalContext
for managing the locks:
GlobalContext::acquire_package_cache_lock
— Acquires a lock. May block if another process holds a lock.GlobalContext::try_acquire_package_cache_lock
— Acquires a lock, returning immediately if it would block.GlobalContext::assert_package_cache_locked
— This is used to ensure the proper lock is being held.
Lower-level code that accesses the package cache typically just use
assert_package_cache_locked
to ensure that the correct lock is being
held. Higher-level code is responsible for acquiring the appropriate lock,
and holding it during the duration that it is performing its operation.
§Types of locking
There are three styles of locks:
CacheLockMode::DownloadExclusive
– This is an exclusive lock acquired while downloading packages and doing resolution.CacheLockMode::Shared
– This is a shared lock acquired while a build is running. In other words, whenever cargo just needs to read from the cache, it should hold this lock. This is here to ensure that no cargos are trying to read the source caches when cache garbage collection runs.CacheLockMode::MutateExclusive
– This is an exclusive lock acquired whenever needing to modify existing source files (for example, with cache garbage collection). This is acquired to make sure that no other cargo is reading from the cache.
Importantly, a DownloadExclusive
lock does not interfere with a
Shared
lock. The download process generally does not modify source files
(it only adds new ones), so other cargos should be able to safely proceed
in reading source files1.
See the CacheLockMode
enum docs for more details on when the different
modes should be used.
§Locking implementation details
This is implemented by two separate lock files, the “download” one and the
“mutate” one. The MutateExclusive
lock acquired both the “mutate” and
“download” locks. The Shared
lock acquires the “mutate” lock in share
mode.
An important rule is that MutateExclusive
acquires the locks in the
order “mutate” first and then the “download”. That helps prevent
deadlocks. It is not allowed for a cargo to first acquire a
DownloadExclusive
lock and then a Shared
lock because that would open
it up for deadlock.
Another rule is that there should be only one CacheLocker
per process
to uphold the ordering rules. You could in theory have multiple if you
could ensure that other threads would make progress and drop a lock, but
cargo is not architected that way.
It is safe to recursively acquire a lock as many times as you want.
§Interaction with older cargos
Before version 1.74, cargo only acquired the DownloadExclusive
lock when
downloading and doing resolution. Newer cargos that acquire
MutateExclusive
should still correctly block when an old cargo is
downloading (because it also acquires DownloadExclusive
), but they do
not properly coordinate when an old cargo is in the build phase (because
it holds no locks). This isn’t expected to be much of a problem because
the intended use of mutating the cache is only to delete old contents
which aren’t currently being used. It is possible for there to be a
conflict, particularly if the user manually deletes the entire cache, but
it is not expected for this scenario to happen too often, and the only
consequence is that one side or the other encounters an error and needs to
retry.
A minor caveat is that downloads will delete an existing
src
directory if it was extracted via an old cargo. Seecrate::sources::registry::RegistrySource::unpack_package
. This should probably be fixed, but is unlikely to be a problem if the user is only using versions of cargo with the same deletion logic. ↩
Structs§
- A held lock guard.
- A locker that can be used to acquire locks.
- The state of the
CacheLocker
. - A file lock, with a counter to assist with recursive locking.
Enums§
- Whether or not a lock attempt should block.
- The style of lock to acquire.
- Whether or not a lock attempt blocked or succeeded.
Constants§
- The filename for the
CacheLockMode::DownloadExclusive
lock. - The filename for the
CacheLockMode::MutateExclusive
andCacheLockMode::Shared
lock.
Functions§
- Returns whether or not the error appears to be from a read-only filesystem.