Description
From what I can tell via my instrumentation of workcache.rs and rustpkg, it appears like the workcache will blithely overwrite the backing database file if you have two simultaneous instances with the same backing store.
I should be clear here: If a client is aware of this behavior, and does not assume anything about whether cache results survive from run to run, then maybe they will be fine. (So whether or not the workcache is strictly speaking "re-entrant" depends on how strong a specification we are expected it to satisfy.)
As in, consider this order of events:
No initial file. WC1 and WC1 will both be setup with the same non-existing path.
WC1 starts; no file to load
WC2 starts; no file to load
each gathers its own local data
WC2 dropped: it outputs its database
WC1 dropped: it outputs its database, and overwrites WC2 results.
This means that you cannot treat the cache results as something you can rely upon being there.
From what I can tell, one or more of the rustpkg tests has one invocation of rustpkg nested within another one, analogous to the WC1/WC2 outline above.
I believe this, perhaps among other things, is what is causing tests::test_c_dependency_no_rebuilding to fail on my platform.