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

[Argyrios Kyrtzidis]

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.

> Cheers,
> /Manuel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140227/1eff4852/attachment.html>