[PATCH] D48051: LTO: Work around a Windows kernel bug by keeping file handles open for memory mapped files.

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 11 16:38:06 PDT 2018


pcc added a comment.

In https://reviews.llvm.org/D48051#1129117, @zturner wrote:

> In https://reviews.llvm.org/D48051#1129112, @pcc wrote:
>
> > In https://reviews.llvm.org/D48051#1129090, @zturner wrote:
> >
> > > Do we have any kind of guarantee that one entity will outlive all other entities that may attempt to share the file?
> >
> >
> > I don't think so, basically the process that creates a cache entry could exit at any time before or after any processes that might read the cache entry.
>
>
> What happens if process A creates a cache entry, then exits, then process B tries to re-use the same cache entry?  Since it got closed (and deleted) before anyone could try to re-use it, does it just create it again?


It doesn't normally get deleted because we clear the delete-on-close bit. It might get deleted later as a result of cache pruning, but that's a separate mechanism. But if it does get deleted through cache pruning, we do create it again.

> It seems like it would be more efficient from a hit/miss ratio perspective if once a cache file was created, it would never be created again.

That's exactly what happens, provided that the cache entry isn't pruned.


https://reviews.llvm.org/D48051





More information about the llvm-commits mailing list