[PATCH] D27768: COFF: Open and map input files asynchronously on Windows.

[Peter Collingbourne via Phabricator via llvm-commits]

pcc added a comment.

In https://reviews.llvm.org/D27768#623208, @ruiu wrote:

> I don't know for sure, but I guess that resources associated with a file descriptor are freed when all references to the descriptor is released. If you mmap a file descriptor and close it, that close is at the moment almost no-op (except it decrements a kernel internal counter by one), and the resources associated with it will be released when you munmap, no?


I don't think that's quite right on Windows. According to [0], on Windows file descriptors are distinct from, and a more limited resource as compared to, OS-level handles (the default limit on the number of file descriptors is 512, and it's possible to increase it to up to 2048; OS-level handles are effectively unlimited). Until now we have only been using file descriptors ephemerally (on Windows MemoryBuffer::getFile will create a handle, create a descriptor from that, extract the handle from the descriptor to map the file and finally close the descriptor), so this hasn't been a problem before. But now descriptors can potentially live much longer.

All of that suggests a cleaner fix: change LLVM's MemoryBuffer API so that it uses handles on Windows. That's probably way outside of the scope of this patch, though. Perhaps we can go back to the earlier version with a FIXME?

[0] http://stackoverflow.com/questions/870173/is-there-a-limit-on-number-of-open-files-in-windows


https://reviews.llvm.org/D27768