nix-super/src/libstore/pathlocks.cc

#include "pathlocks.hh"
#include "util.hh"
#include "sync.hh"
#include "signals.hh"

#include <cerrno>
#include <cstdlib>


namespace nix {

PathLocks::PathLocks()
    : deletePaths(false)
{
}


PathLocks::PathLocks(const PathSet & paths, const std::string & waitMsg)
    : deletePaths(false)
{
    lockPaths(paths, waitMsg);
}


PathLocks::~PathLocks()
{
    try {
        unlock();
    } catch (...) {
        ignoreException();
    }
}


void PathLocks::setDeletion(bool deletePaths)
{
    this->deletePaths = deletePaths;
}


}
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-05 00:06:23 +03:00			`#include "pathlocks.hh"`
			`#include "util.hh"`
Probably fix a segfault in PathLocks 2016-12-09 14:26:43 +02:00			`#include "sync.hh"`
Split up `util.{hh,cc}` All OS and IO operations should be moved out, leaving only some misc portable pure functions. This is useful to avoid copious CPP when doing things like Windows and Emscripten ports. Newly exposed functions to break cycles: - `restoreSignals` - `updateWindowSize` 2023-10-25 07:43:36 +03:00			`#include "signals.hh"`
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-05 00:06:23 +03:00
* Added some missing #includes. 2003-09-11 11:31:29 +03:00			`#include <cerrno>`
* GCC 4.3.0 (Fedora 9) compatibility fixes. Reported by Gour and Armijn Hemel. 2008-05-21 14:17:31 +03:00			`#include <cstdlib>`
* Added some missing #includes. 2003-09-11 11:31:29 +03:00
* normaliseFState() now locks all output paths prior to building, thus ensuring that simultaneous invocations of Nix don't clobber each other's builds. * Fixed a bug in `make install'. 2003-08-01 17:11:19 +03:00
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-05 00:06:23 +03:00			`namespace nix {`

* True parallel builds. Nix can now run as many build jobs in parallel as possible (similar to GNU Make's `-j' switch). This is useful on SMP systems, but it is especially useful for doing builds on multiple machines. The idea is that a large derivation is initiated on one master machine, which then distributes sub-derivations to any number of slave machines. This should not happen synchronously or in lock-step, so the master must be capable of dealing with multiple parallel build jobs. We now have the infrastructure to support this. TODO: substitutes are currently broken. 2004-05-11 21:05:44 +03:00			`PathLocks::PathLocks()`
* Remove lock files after building. 2003-11-21 18:05:19 +02:00			`: deletePaths(false)`
* normaliseFState() now locks all output paths prior to building, thus ensuring that simultaneous invocations of Nix don't clobber each other's builds. * Fixed a bug in `make install'. 2003-08-01 17:11:19 +03:00			`{`
* True parallel builds. Nix can now run as many build jobs in parallel as possible (similar to GNU Make's `-j' switch). This is useful on SMP systems, but it is especially useful for doing builds on multiple machines. The idea is that a large derivation is initiated on one master machine, which then distributes sub-derivations to any number of slave machines. This should not happen synchronously or in lock-step, so the master must be capable of dealing with multiple parallel build jobs. We now have the infrastructure to support this. TODO: substitutes are currently broken. 2004-05-11 21:05:44 +03:00			`}`


Remove std::string alias (for real this time) Also use std::string_view in a few more places. 2022-02-25 17:00:00 +02:00			`PathLocks::PathLocks(const PathSet & paths, const std::string & waitMsg)`
* True parallel builds. Nix can now run as many build jobs in parallel as possible (similar to GNU Make's `-j' switch). This is useful on SMP systems, but it is especially useful for doing builds on multiple machines. The idea is that a large derivation is initiated on one master machine, which then distributes sub-derivations to any number of slave machines. This should not happen synchronously or in lock-step, so the master must be capable of dealing with multiple parallel build jobs. We now have the infrastructure to support this. TODO: substitutes are currently broken. 2004-05-11 21:05:44 +03:00			`: deletePaths(false)`
			`{`
* In `nix-env -i\|-u\|-e', lock the profile to prevent races between concurrent nix-env operations on the same profile. Fixes NIX-7. 2006-06-15 14:56:49 +03:00			`lockPaths(paths, waitMsg);`
* True parallel builds. Nix can now run as many build jobs in parallel as possible (similar to GNU Make's `-j' switch). This is useful on SMP systems, but it is especially useful for doing builds on multiple machines. The idea is that a large derivation is initiated on one master machine, which then distributes sub-derivations to any number of slave machines. This should not happen synchronously or in lock-step, so the master must be capable of dealing with multiple parallel build jobs. We now have the infrastructure to support this. TODO: substitutes are currently broken. 2004-05-11 21:05:44 +03:00			`}`


* normaliseFState() now locks all output paths prior to building, thus ensuring that simultaneous invocations of Nix don't clobber each other's builds. * Fixed a bug in `make install'. 2003-08-01 17:11:19 +03:00			`PathLocks::~PathLocks()`
* Release output locks as soon as possible, not when the destructor of the DerivationGoal runs. Otherwise, if a goal is a top-level goal, then the lock won't be released until nix-store finishes. With --keep-going and lots of top-level goals, it's possible to run out of file descriptors (this happened sometimes in the build farm for Nixpkgs). Also, for failed derivation, it won't be possible to build it again until the lock is released. * Idem for locks on build users: these weren't released in a timely manner for failed top-level derivation goals. So if there were more than (say) 10 such failed builds, you would get an error about having run out of build users. 2009-02-16 11:24:20 +02:00			`{`
~PathLocks(): Handle exceptions Otherwise, since the call to write a "d" character to the lock file can fail with ENOSPC, we can get an unhandled exception resulting in a call to terminate(). 2016-01-04 12:32:46 +02:00			`try {`
			`unlock();`
			`} catch (...) {`
			`ignoreException();`
			`}`
* Release output locks as soon as possible, not when the destructor of the DerivationGoal runs. Otherwise, if a goal is a top-level goal, then the lock won't be released until nix-store finishes. With --keep-going and lots of top-level goals, it's possible to run out of file descriptors (this happened sometimes in the build farm for Nixpkgs). Also, for failed derivation, it won't be possible to build it again until the lock is released. * Idem for locks on build users: these weren't released in a timely manner for failed top-level derivation goals. So if there were more than (say) 10 such failed builds, you would get an error about having run out of build users. 2009-02-16 11:24:20 +02:00			`}`


* Remove lock files after building. 2003-11-21 18:05:19 +02:00			`void PathLocks::setDeletion(bool deletePaths)`
			`{`
			`this->deletePaths = deletePaths;`
* normaliseFState() now locks all output paths prior to building, thus ensuring that simultaneous invocations of Nix don't clobber each other's builds. * Fixed a bug in `make install'. 2003-08-01 17:11:19 +03:00			`}`
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-05 00:06:23 +03:00
* Fix a race condition with parallel builds where multiple fixed-output derivations or substitutions try to build the same store path at the same time. Locking generally catches this, but not between multiple goals in the same process. This happened especially often (actually, only) in the build farm with fetchurl downloads of the same file being executed on multiple machines and then copied back to the main machine where they would clobber each other (NIXBF-13). Solution: if a goal notices that the output path is already locked, then go to sleep until another goal finishes (hopefully the one locking the path) and try again. 2007-08-28 14:36:17 +03:00
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-05 00:06:23 +03:00			`}`