D16218: [KDevelop/Core]: safe signal-handler implementation (WIP)

[René J.V. Bertin]

rjvbb added a comment.


  >   This is determined by hardware support. With relevant architectures I meant architectures on which Qt/KDE applications can run, like x86, PPC, ARM. > These all have lock-free `std::atomic<bool>`, as far as I know.
  
  <aside>
  I presume that underneath this would use "intrinsics" like _InterlockedIncrement does (https://github.com/RJVB/SynchroTr/blob/master/CritSectEx/msemul.h#L548) so yeah, hardware determined. But the standard depends on software and this could decide to use locks under certain conditions. Even runtime conditions if that same standard doesn't guarantee it won't.
  That's requires a pretty intimate knowledge of both the standard and its implementation(s), and I guess that's why the StackOverflow discussions I've seen seem to agree that it's best to avoid std::atomic<?> if it being lock free is a hard requirement.

REPOSITORY
  R32 KDevelop

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

To: rjvbb, #kdevelop, kfunk
Cc: aaronpuchert, brauch, kfunk, arrowd, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20181018/26c9215b/attachment.html>