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

[Ivan Koster]

>
> 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.
>

I tried some different editors and commands on the file

Fails to write file: Sublime text 2, notepad++
Can write file: Visual studio 2013, windows notepad

Fails to delete file: explorer.exe, Total Commander
Can delete file: del command on commandline

Funny, but painful, how they all act different.

So if this boils down to libclang keeping this file mapped in memory (with
sharemode to only read) around to provide an AST and functionality to
external tools, maybe the sharemode could be relaxed from read only to
read/write/delete when not actively compiling?
Or maybe the external tool should be able to tell libclang to clean the
mapping up?
I briefly looked at the C api and saw many "dispose" functions. Will
functions like clang_disposeTranslationUnit() not clean up the file mapping?

I hope this is not a too uninformed suggestion!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141211/9e507d75/attachment.html>