the other completers already inherit one through EvalState. all of them
eventually need it since completing a flake ref may require network io.
Change-Id: Ie664a129a68457a6f0908d226057d7d7fb610ae4
the LocalStore implementation calls `getDefaultSubstituters`, which
calls `openStore`, which calls `Store::init`, which does network io
in binary caches, which will eventually be properly asyncified curl
Change-Id: If6a7a0294e2c4ba8e35722583be6ccde21ed6585
we now allow for single locked paths rather than only sets, the lock
holder classes are finally resource-safe, and not locking files from
within constructors means we can (in theory!) make path locks async.
Change-Id: I1e1807299d370c07b15c332d5b2ff77b64456e7d
they are not being created with O_EXCL and their existence is not
checked for using the PathLocks api, so we will boldy assume that
*nothing* checks for lock file existence. deleting lockfiles when
we're done with them in all cases makes the code cleaner, and any
failing builds no longer litter their store with stale lockfiles.
Change-Id: Iffb588d29b00e6aca32fcb6776980455238ac2bd
the local store doesn't have to block the entire thread waiting for a
lock with such support. we'll still block *some* thread, but there is
currently no good way around that without e.g. a lock manager daemon.
Change-Id: I037fdc749e1b56cf9e0f1ca7ac70274442fb2b8c
since constructors can't actually be async we need a static wrapper
function that does the async work. it's fine, rust survives it too.
Change-Id: Ifa13d6f96d5a8b5b7fe215530b6eba24ef921d6d
this needs a new method because overloading rules would make a pair of
methods taking `std::function`s of different argument types ambiguous.
we could've turned enqueue into a template and made `enqueueWithAio` a
private method too, but the necessary template magic is wasted on this
Change-Id: I93ccfde07126c287ad2a4dc5a07caec6a9d83944
signals could cause lockFile to return without having locked the file.
the garbage collector didn't check for this, and then hilarity ensued.
Change-Id: If86d33595e8bf5510d2b032139342261dc6e07c9
lockFile is currently interruptible by signals like SIGCHLD. which
happen a lot in daemons. now imagine that daemon enabled automatic
garbage collection. observe that the local store does not actually
check whether its lock operations have succeeded ... get the idea?
Change-Id: Ibfd7ee786c4fee3add72d4456a7e95e73e09c73e
propagating the "unlock" lock type through this high-level api is
nonsense. it doesn't make sense to treat locking and unlocking as
similar operations; unlocking *must* not not interruptible by our
checkInterrupt machinery or it will just leave locks lying around
for a potentially very long time. unlock operations should not be
taking long enough to *want* them interrupted anyway. even on nfs
this makes very little sense because nfs waits *uninterruptibly*.
Change-Id: I10d605c8fe6c651bee64466eee1f8e20251d39f4
eldritch horrors