<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 5, 2017 at 10:51 AM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>What I mean is that you could have a system-wide named mutex with a unique name that involves a 128-bit GUID or something.  All ThinLTO linker processes could agree on this name from now until forever.  This would presist across linker invocations because the name of the mutex never changes.  This would synchronize access to a single "cache control file" that also had a globally unique (and unchanging) name.  So the algorithm for opening a file from the cache is:</div><div><br></div><div>1) Acquire the mutex</div><div>2) Try to open the file and either succeed or fail</div><div>3) Close the mutex.</div><div><br></div><div>and the algorithm for adding a new file to the cache is:</div><div><br></div><div>1) Acquire the mutex</div><div>2) Do whatever it takes to get a new file into the cache</div><div>3) Close the mutex</div><div><br></div><div>This should never race.</div></div></div>
</blockquote></div><br></div><div class="gmail_extra">This patch makes our rename more POSIX-y. That seems like an objectively good thing, regardless of what the best way to implement a shared, persistent cache is on Windows. In the long run, this sounds like something that could replace LLVM's probably hopelessly broken lock file implementation on Windows.<br></div></div>