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

[Ben Langmuir]

On Feb 27, 2014, at 8:00 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:

> 
> On Feb 27, 2014, at 4:43 AM, Manuel Klimek <klimek at google.com> wrote:
> 
>> On Thu, Feb 27, 2014 at 1:37 PM, Manuel Klimek <klimek at google.com> wrote:
>> On Wed, Feb 12, 2014 at 11:22 PM, Douglas Gregor <dgregor at apple.com> wrote:
>> 
>> On Feb 12, 2014, at 2:21 PM, Rafael Ávila de Espíndola <rafael.espindola at gmail.com> wrote:
>> 
>> >
>> >
>> > ================
>> > Comment at: include/clang/Basic/FileManager.h:122
>> > @@ -121,2 +121,3 @@
>> > class FileManager : public RefCountedBase<FileManager> {
>> > +  IntrusiveRefCntPtr<AbstractFileSystem> FS;
>> >   FileSystemOptions FileSystemOpts;
>> > ----------------
>> > Why is the reference count necessary? Given its nature I would expect the FS to outlive the file manger, in which case the FileManager could have just a pointer to the FileSystem.
>> 
>> 
>> The FS is likely to get shared among a number of FileManagers in different compiler instances within a thread. Yes, we could try to establish and maintain relationships among these, but it’s simpler and costs us effectively nothing to make this ref-counted.
>> 
>> Just to follow up:
>> I found one more argument against making this ref-counted:
>> The constructor of FileManager that uses the default "real" file system is now actively thread hostile (you cannot create a FileManager per thread without locking). I think that's rather unexpected.
>> 
>> And even worse, because RealFileSystem is an implementation detail, and getRealFileSystem returns a ref counted pointer by value, I cannot see any way to get me a RealFileSystem without locking.
>> 
> 
> I propose we introduce a RefCountedBase that is using atomic reference count (either change RefCountedBase or add a new class), and have FileSystem use that.
> 

Makes sense to me.  Manuel, does this address your concern?

Ben

>> Cheers,
>> /Manuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140303/7f3c2a9a/attachment.html>