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