ChuanqiXu9 wrote: > > * Now the ScanningProjectModules are owned by different calls to > > `ModulesBuilder::buildPrerequisiteModulesFor`. So we don't need to care > > about thread safety in ScanningProjectModules. And if we make it the > > underlying ProjectModules, we need to care about the thead safety and then > > we would have a centralized scanner. It is not bad but it might be a bigger > > change. > > Not sure I understand the argument here. Please note that I am not suggesting > to store a `ScanningProjectModules` (or any other `ProjectModules`) inside > `CachingProjectModules`. We can't even if we wanted to, in theory any source > file can belong to a different `ProjectModules`. Hence we store the > `GlobalCompilationDatabase`, so that we can access a relevant > `ProjectModules` when the cache is invalid or we don't have an entry. Hence > we're not sharing any `ScanningProjectModules` instances across threads. > > As for thread-safety concerns in `CachingProjectModules` itself, I think we > have the exact same requirements as this patch > (https://github.com/llvm/llvm-project/pull/125988/files#diff-bfbef59d036ce319b5ed9b774f6ddb8dcd7efdba3384de03cb9a37f23ef678ba), > basically underlying cache can be accessed concurrently, but rest should be > outside the critical path. > > Does that make sense? If not could you elaborate on your concern?
Yeah, I though you were saying to store the underlying ProjectModules. Now it is fine. https://github.com/llvm/llvm-project/pull/125988 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
