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

[René J.V. Bertin]

rjvbb added a comment.


  >   You can't use std::atomic_flag, because it's an `int`. 
  
  Yes, I realised that when I started tinkering with the various std::atomic* types.
  
  >   There is a race condition anyway which you won't get rid of using atomics: another signal could have overwritten `signalReceived` before you read it.
  
  Indeed. I did use the value written to the pipe at first, but that feels a bit awkward and I don't know to what extent we can be certain that the read won't block and/or will always read the actual (entire) value.
  Either way, I decided that this race condition is not an issue:
  
  - signalReceived can only take values that correspond to the signals we handle
  - currently all signals trigger the same series of reactions
  - if 2 signals arrive so quickly one after another that the socketnotifier didn't have time to react it doesn't seem unreasonable to let the later signal override the earlier signal.

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