D22182: Remove anchorClicked lock which causes deadlock

[Aaron Puchert]

aaronpuchert added a comment.


  In D22182#490532 <https://phabricator.kde.org/D22182#490532>, @mswan wrote:
  
  > Interesting. I have experimented with this a bit and I cannot find a way to articulate to the thread safety system that my lock and unlock functions are idempotent. If I call `lock.unlock()` and later return without locking it again, I get a warning (or rather an error because I set `-Werror=thread-safety`) that complains that I am releasing a lock that isn't held. So would `-Wno-error=thread-safety-negative` allow us to get around that or is there possibly some other solution?
  
  
  Lock and unlock shouldn't be idempotent. There are recursive/reentrant mutexes <https://en.wikipedia.org/wiki/Reentrant_mutex>, which can be locked multiple times, but must be unlocked the same number of times. They are rarely needed though, do we want that here?
  
  If you assume the lock is initially held, and want to return with the lock released, you need to annotate the function with `__attribute__((release_capability(lock)))`.
  
  I'm just having a lock at the DUChain locking and try to figure out what the best way would be. It's a bit of a problem that we're not exactly doing it "by the book" sometimes, such as when scoped locks are handed as parameters to functions. But there is usually a way around that.

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/6f22aa64/attachment.html>