On Feb 12, 2014, at 3:45 PM, Rafael Espíndola <[email protected]> 
wrote:

>> I have no idea what you mean by “clang process”. You don’t actually mean the 
>> whole process itself, because FS isn’t thread-safe and therefore isn’t some 
>> kind of global singleton. Plus, different invocations of the compiler may 
>> have different FS, so making this a global singleton is completely wrong . 
>> Any thread-specific “singleton” would be wrong for the same reasons.
>> 
>> I guess we could toss the responsibility for managing the FS instance up to 
>> “the client”, but which clients are those? Some clients will want to 
>> pre-populate and widely share a FS, while others just want 
>> CompilerInvocation to create the FS if the command-line arguments passed 
>> through to it require the FS. We want to support the former without 
>> complicating the latter. IntrusiveRefCntPtr makes that easy to do with 
>> completely acceptable overhead.
> 
> OK, if that is the use case, then I agree with IntrusiveRefCntPtr, but
> that means I misunderstood how the FS is to be used.
> 
> My understanding was that the FS would always be shared, so that it
> could be constructed once as close to main as possible. Would you mind
> explaining when we would want two different FS alive in the same
> process (or thread)?

The FS can be created by passing a not-yet-implemented “-vfs <file>” argument 
to Clang, which will allocate and populate a virtual file system based on the 
input file. If I were writing a Clang compiler server, I wouldn’t want to share 
the virtual file systems of distinct Clang invocations.

> Now I realize that maybe I just missed that this is to be exposed via
> libclang and we can assume nothing about how the clients want to use
> FS?


VFS file creation routines will be exposed by libclang. That’s one of the 
clients… an IDE that has edited files in memory that it doesn’t want to flush 
to disk before invoking Clang.

        - Doug


_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to