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

Zachary Turner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 11 16:26:10 PDT 2018


zturner added a comment.

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 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 would also sidestep this problem because we wouldn't even have to use `FILE_FLAG_DELETE_ON_CLOSE` in the first place, you could wipe the cache at the beginning of a multi-process link operation and let it build up over time as processes spawn and die.

I'm concerned that we're tacking more and more complexity and strange combinations of flags and sequences of operations that we're just inviting even more (and even harder to find) problems.


https://reviews.llvm.org/D48051





More information about the llvm-commits mailing list