D22182: Remove anchorClicked lock which causes deadlock

Michael Swan noreply at phabricator.kde.org
Thu Jul 4 03:03:44 BST 2019


mswan added a comment.


  In D22182#490536 <https://phabricator.kde.org/D22182#490536>, @aaronpuchert wrote:
  
  > Hmm, you're right. Maybe we can get rid of that when we're certain through static checking that this isn't needed anymore.
  
  
  Well at least the destructor will need that behaviour because it is certainly sane behaviour for someone to unlock a lock somewhere along the line and then leave it unlocked till the end of the function, e.g. the code I included with this ticket. There didn't seem to be a way that I could scope that lock because this lock was needed for an local constructor invocation.
  
  > In D22182#490535 <https://phabricator.kde.org/D22182#490535>, @mswan wrote:
  > 
  >>
  > 
  > 
  > 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."
  
  I have actually tried changing my experiment with clang's thread safety to use the scoping feature and I seem to be seeing a new issue with these destructors with an error like "lock using shared access, expecte

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/cdbfd40d/attachment-0001.html>


More information about the KDevelop-devel mailing list