* Store user environment manifests as a Nix expression in
$out/manifest.nix rather than as an ATerm. (Hm, I thought I committed this two days ago...)
This commit is contained in:
parent
f3b8833a48
commit
fe2d869e04
11 changed files with 205 additions and 183 deletions
|
|
@ -2,6 +2,7 @@
|
|||
#define __PROFILES_H
|
||||
|
||||
#include "types.hh"
|
||||
#include "pathlocks.hh"
|
||||
|
||||
#include <time.h>
|
||||
|
||||
|
|
@ -37,6 +38,20 @@ void deleteGeneration(const Path & profile, unsigned int gen);
|
|||
|
||||
void switchLink(Path link, Path target);
|
||||
|
||||
/* Ensure exclusive access to a profile. Any command that modifies
|
||||
the profile first acquires this lock. */
|
||||
void lockProfile(PathLocks & lock, const Path & profile);
|
||||
|
||||
/* Optimistic locking is used by long-running operations like `nix-env
|
||||
-i'. Instead of acquiring the exclusive lock for the entire
|
||||
duration of the operation, we just perform the operation
|
||||
optimistically (without an exclusive lock), and check at the end
|
||||
whether the profile changed while we were busy (i.e., the symlink
|
||||
target changed). If so, the operation is restarted. Restarting is
|
||||
generally cheap, since the build results are still in the Nix
|
||||
store. Most of the time, only the user environment has to be
|
||||
rebuilt. */
|
||||
string optimisticLockProfile(const Path & profile);
|
||||
|
||||
}
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue