kadircet 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? 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
