labath added a comment. In D65329#1604847 <https://reviews.llvm.org/D65329#1604847>, @clayborg wrote:
> We will need to watch future submissions closely as this increases the chance > that someone will extend a SymbolFile by overriding a virtual function and > forget to lock. I've though about addressing that by moving the actual implementations into private versions of these functions, and putting the locking into public functions which would just take the lock and then call the private version (essentially doing the same thing as it's done now, only without the methods being on different classes). I didn't do that now because: a) it wouldn't make SymbolFileDWARF consistent anyway as it already has private methods which take the module lock b) it forces a certain locking pattern on all the subclasses, whereas some subclasses could potentially want to implement a different locking strategy CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65329/new/ https://reviews.llvm.org/D65329 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
