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

>> Look at CompilerInstance. It has a number of IntrusiveRefCntPtr’s that exist 
>> because we consistently ran into problems with other clients needing to hold 
>> onto these core, cooperating objects for longer than the given 
>> CompilerInstance. ASTUnit is one of the major culprits here, but it’s not 
>> the only one.
> 
> Yes. I am not suggesting for CompilerInstance to own the FS. That
> would be really odd.

Unique ownership would be odd; shared ownership is not.

>>> But is it not the case that
>>> * A clang process will always use a single FS.
>>> * The decision as to which to use can happen just after parsing the
>>> command line arguments?
>> 
>> 
>> We may spawn a number of Clang invocations within the same thread to build 
>> modules from headers, and they all need to share the same FS.
> 
> Which perfectly matches to having a FS being constructed before any
> CompilerInstance and each CompilerInstance has a pointer to the same
> FS. In other words, a FS is a singleton in a clang process, no?


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.

        - Doug


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

Reply via email to