Using time_t meant a warning could be printed arbitrarily soon depending
on when the second rolled over relative to when the SQLite transaction
was attempted.
Change-Id: I93401aea65f90e37cd450a293c4dd4d64fba7628
the two instances that used synchronous locking from promises weren't in
danger of deadlocks: both only serialized access to the sqlite database.
Change-Id: I2041a7a31f39cffde2080d0bb2402e2ead8d953f
while these two are currently safe using synchronous mutexes we can't
easily guarantee this forever. since we have async mutexes too now we
may as well use them; the overhead they incur is small enough that we
can just ignore it here. this can be revisited later, when necessary.
Change-Id: Ia4cb2361d5638aa48e3b982a05e75ae9c4f254cd
we can't use Sync with stl mutex types since yielding from one coroutine
to another while holding a lock is a deadlock hazard. if we don't expose
blocking lock operations from Sync though and emulate blocking with more
promises we can reuse most of the Sync code instead of rewriting it all.
hiding them completely would make it impossible to migrate current users
to promise-based code though, so we use our new NeverAsync lint instead.
Change-Id: I7eebf18e29473963040e7448da27c52012f1f134
gc tryLocks first, then deletes. we can use the same order since there's
no sequence of operations that would let us lock our new directory *and*
have the gc delete it (except outright bugs). the worst possible outcome
is that we create a few directories that'll be deleted by a later gc run
Change-Id: I6d3524f4990f8deee10804e6fbb0d0a26f3d57fe
we now create a temporary file, lock it, move it into place, and return.
if any of these steps (except creation) fails the GC must have found and
deleted our new file before we got the chance to use it. we don't need a
lock around file creation anymore, we especially don't need a mutex that
covers an flock call, and we don't need the GC to clobber what it finds.
(clobbering *is* kept for compatibility with older nix implementations.)
if we ever leave trash around it'll be cleaned up by some future gc run.
Change-Id: I078ae55fb7a9dfcdae28d6917d138842188ed528
sadly we need both a synchronous and an asynchronous promise for this
since destructors cannot be async. we also cannot use forked promises
since multiple threads may be waiting for an auto-gc to complete, but
forked promises are bound to an event loop (and thus a single thread)
Change-Id: I7b4fdbd229c4a1e01bbf80858e93347024f2e333
constructors can't be async, and root creation must be made async.
creating roots outside of goal classes and passing a witness type
is a lot easier than changing the constructor structure of today.
Change-Id: Ic84a92f3db2e1a9a9164047456f227048c6871bd
addMultipleToStore calls addToStore through processGraph, so for now we
need an aio root in processGraph callbacks. eventually we'll drop them,
but that can only be done once we know that the single-threaded runtime
will not get deadlocked. the threads guarantee progress, for time being
Change-Id: I62869a72ef8085c508609a8d4274330e004ab685
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
Lily Ballard