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

[Aaron Puchert]

aaronpuchert added a comment.


  In D16218#345150 <https://phabricator.kde.org/D16218#345150>, @rjvbb wrote:
  
  > So is it enough to change to std::atomic_flag or should we use some sort of critical section with an actual lock? Because for handlingSignal that's possible as it is outside of the actual signal handler.
  
  
  A lock is not needed. Just change the if to `if (!test_and_set()) { ... }` if you go with `std::atomic_flag`.
  
  By the way, since `shutdownGracefully` is no longer the actual signal handler, it wouldn't be a problem if it weren't lock-free.
  
  > Should I use std::atomic_flag for the m_signalReceived member too?
  
  You can't use std::atomic_flag, because it's an `int`. 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. The good news is that we don't need the variable at all: since you write `sig` to the pipe, you should be able to read it at the other end, and you should probably get multiple signals in the right order.
  
  > It seems in fact that the gracefulExit *slot* is not being called at all when a previous call is ongoing; are you sure Qt doesn't prevent that from happening but instead queues signals for sequential delivery? If so your concern seems moot.
  
  It's possible that either the OS decides not to interrupt the signal handler or that Qt serializes (Qt) signals. I don't know. I was just saying that //if// the `if` is necessary, then it must test and set the flag atomically.

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