D22182: Remove anchorClicked lock which causes deadlock

Aaron Puchert noreply at phabricator.kde.org
Thu Jul 4 02:42:58 BST 2019


aaronpuchert added a comment.


  In D22182#490534 <https://phabricator.kde.org/D22182#490534>, @mswan wrote:
  
  > I agree, but in the current implementation they are see `DUChainReadLocker::lock()` and `DUChainReadLocker::unlock()`, they both check if we are already locked before continuing to lock or unlock respectively.
  
  
  Hmm, you're right. Maybe we can get rid of that when we're certain through static checking that this isn't needed anymore.
  
  In D22182#490535 <https://phabricator.kde.org/D22182#490535>, @mswan wrote:
  
  > It is somewhat convenient that the destructor idempotent behaviour  is the way it is. I don't want to invoke `lock.lock()` at the end of every function to satisfy that destructor and I also wouldn't want to get rid of that destructor behaviour.
  
  
  That's no problem, the destructor doesn't need the lock being held. See https://github.com/llvm/llvm-project/blob/llvmorg-8.0.0/clang/lib/Analysis/ThreadSafety.cpp#L965-L967: the warning is only emitted "if we're not destroying the scoped object."

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D22182

To: mswan, #kdevelop
Cc: aaronpuchert, kdevelop-devel, hmitonneau, christiant, glebaccon, domson, antismap, iodelay, alexeymin, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20190704/b6d9fa00/attachment.html>


More information about the KDevelop-devel mailing list