[PATCH] Some infrastructure work for virtual file system (now on phab)

Douglas Gregor dgregor at apple.com
Wed Feb 12 15:00:31 PST 2014


On Feb 12, 2014, at 2:41 PM, Rafael Espíndola <rafael.espindola at gmail.com> 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





More information about the cfe-commits mailing list