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

[René J.V. Bertin]

rjvbb marked an inline comment as done.
rjvbb added a comment.


  > At least `std::atomic<bool>` is lock-free on all relevant architectures. (I'm aware that the standard doesn't guarantee it, probably because of some embedded architectures.
  
  But is it always lock-free on the relevant architectures? Or rather:
  
  - what determines if the type is lock-free
  - what are "the relevant architectures"?
  
  >> rjvbb wrote in core.cpp:68-69
  > 
  > Either two signals can be handled at the same time, then it needs to be thread-safe
  
  A signal that arrives before the previous has been handled, that would probably be on the same (= main) thread and thus require reentrancy (I always forget if that's more or less strict than thread safety). Atomic variables protect against multiple threads accessing them at the same time AFAIK, but can they do that for concurrent access from the same thread?
  Either way, can a signal handler really be called in the middle of an assignment (to an atomic variable)? If not, then only 1 instance will get access to the inside of the if, no?
  
  > , or there is always only one signal handled at the same time, in which case this `if` isn't needed.
  
  No, because the conditional is static so it gives access into the if only once.
  
  And there's an obvious situation where a 2nd signal can arrive before we're done: when something (in the UI) blocks and the user repeats the kill command.
  
  > But why? If I want an unclean shutdown, I can just send SIGKILL. I don't understand why a second signal should be handled differently than the first.
  
  I guess the idea was to force the exit at the 2nd arrival of one of the caught signals, so you can just use your command history to repeat the same kill command.
  I probably wouldn't have implemented this way either unless I wanted to try something else on the 2nd signal (again, as I intend to do here). But it doesn't bother me either; someone thought it was a good idea in the past, and it makes it easy to add a 2nd chance, "bare bones" clean exit attempt upon receipt of a 2nd signal (or on the 1st in case of a HUP).

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/20181016/ee89f7f6/attachment.html>