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

Kevin Funk noreply at phabricator.kde.org
Mon Oct 15 11:26:16 BST 2018


kfunk added a comment.


  Sorry, but this is yet another unmergeable WIP patch of yours. Just a quick review, I'm not diving into your code (which is difficult to parse, esp. the changes in `CorePrivate::initialize`...) right now.
  
  Questions:
  
  - Why does this patch look so much more verbose than the solution proposed on http://doc.qt.io/qt-5/unix-signals.html?
  - Why the alternative implementations? Why do we need to the non-QSocketNotifier variant? You realize that every "alternative solution" or `#ifdef` puts more maintenance burden on us?
  
  > The actual graceful shutdown routine has been modified slightly: it will call Core::shutdown() when a 2nd signal is received, before raising that signal again. I propose to make this the only action when a SIGHUP is received, in order to speed up the exit procedure and reduce the chances of getting stuck in the normal exit procedure. This seems more in line with the nature of the signal.
  
  Should be a separate patch, I suppose that's close to a one-line patch against the current code base.
  
  Side note: All the signal handling functionality should be factored out into classes/functions as much as possible in order to simplify the code (cf. http://doc.qt.io/qt-5/unix-signals.html again -- it does that nicely).

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

To: rjvbb, #kdevelop
Cc: 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/20181015/96407ba6/attachment-0001.html>


More information about the KDevelop-devel mailing list