<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 5, 2017 at 11:46 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div><div class="gmail-h5"><div dir="ltr">On Thu, Oct 5, 2017 at 11:27 AM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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><div dir="ltr"><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></blockquote><div><br></div></div></div><div>I guess this is a tangent, but if we want to implement robust lock files on Windows, I'd suggest just *actually* <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365202%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396" target="_blank">locking the file</a> and providing an abstraction that hides the details of how a file system lock works, and on Windows just uses this function and on posix relies on a separate file.</div><div><br></div><div>Can we at least *try* to just call MoveFileEx first?  If it fails then we can fall back to the more complicated code-path.  </div></div></div>
</blockquote></div><div class="gmail_extra"><br></div>That might be worth doing if we wanted to pass MOVEFILE_COPY_ALLOWED in order to allow for moving files between file systems. However, we could easily implement that ourselves if needed, and MoveFileEx does not document which sharing mode it opens the source file with, so we're back to the original problem if some version of Windows decides to open it with no sharing.</div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>