I don’t think it is

I know for sure that cleaning the build cache (go cache -clean) while building something is not safe. This is discussed in #31948, which also functions as a TODO for possibly making it safe.

cc @bcmills @jayconrod

I know for sure that cleaning the build cache (go cache -clean) while building something is not safe.

Okay but what about multiple parallel go build or go test invocations?

Okay but what about multiple parallel go build or go test invocations?

This is safe on most file systems. Files are added to the cache atomically, and a global file lock is held when files are evicted. If the file system does not support file locking or atomic renaming, then it may not be safe.

FWIW, the build and test cache does not use file locking, and I don't think it relies on atomic renaming either. (Instead, it writes the expected lengths in metadata files, and overwrites and appends to partial files in-place rather than truncating or deleting them.)

I take that back: we use file-locking in one place in the test cache, to store the expiration date for stale tests.

@alvaroaleman are you hoping to do simultaneous go build/go test runs of the same project, or different ones, or partially overlapping ones?

@networkimprov the question came up in the context of "We prepopulate and then use one cache per machine that runs many concurrent builds"

If prepopulated, is your cache read-only?

If prepopulated, is your cache read-only?

Its not my cache and I believe its not