On Feb 27, 2014, at 4:43 AM, Manuel Klimek <[email protected]> wrote:
> On Thu, Feb 27, 2014 at 1:37 PM, Manuel Klimek <[email protected]> wrote: > On Wed, Feb 12, 2014 at 11:22 PM, Douglas Gregor <[email protected]> wrote: > > On Feb 12, 2014, at 2:21 PM, Rafael Ávila de Espíndola > <[email protected]> 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
