[cfe-dev] libclang locking files for write/delete on windows

[Reid Kleckner]

On Wed, Dec 10, 2014 at 1:45 PM, Ivan Koster <ivankoster at gmail.com> wrote:

> From
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa366537(v=vs.85).aspx
>>
>> Mapped views of a file mapping object maintain internal references to the
>> object, and a file mapping object does not close until all references to it
>> are released. Therefore, to fully close a file mapping object, an
>> application must unmap all mapped views of the file mapping object by
>> calling *UnmapViewOfFile*
>> <http://msdn.microsoft.com/en-us/library/windows/desktop/aa366882(v=vs.85).aspx> and
>> close the file mapping object handle by calling *CloseHandle*
>> <http://msdn.microsoft.com/en-us/library/windows/desktop/ms724211(v=vs.85).aspx>.
>> These functions can be called in any order.
>
>
> Since CloseHandle is already called after the init, it seems the mapped
> view is still open?
> I'm a C and python programmer and (no C++ experience at all) have an
> incredible hard time reading the code.
> Nevertheless, Mapping in mapped_file_region seems to be the only view
> created and it is unmapped in the destructor:
>
> mapped_file_region::~mapped_file_region() {
>>   if (Mapping)
>>     ::UnmapViewOfFile(Mapping);
>> }
>
>
> Can I conclude that the destructor is not called?
>

In normal compilation, the file remains mapped into memory until
compilation is over. Sometimes the AST has pointers to string data embedded
in the code. In YCM, I guess compilation is never "over" so the file stays
mapped indefinitely.

We need to figure out a file mapping strategy that will work on Windows. On
Linux, there are no file locks, and "well behaved" editors generally save
files atomically by writing a temp file and renaming it over the original
file. I don't know what editors on Windows do. If popular editors
(Notepad+, VS, sublime, Vim, etc) rewrite the file in place, then we might
have to give up on the mmap approach, as it will be racy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141210/956813b4/attachment.html>