D16218: [KDevelop/Core]: safe signal-handler implementation (WIP)
Aaron Puchert
noreply at phabricator.kde.org
Sat Oct 20 15:04:30 BST 2018
aaronpuchert accepted this revision as: aaronpuchert.
aaronpuchert added a comment.
The signal handling and processing gets a +1 from me, but someone else should review the overall code structure.
In D16218#343364 <https://phabricator.kde.org/D16218#343364>, @kfunk wrote:
> 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).
Arguably that still stands, but it's outside my area of expertise to comment on it.
INLINE COMMENTS
> core.cpp:68-69
> + // Get the signal number that was written to the pipe in the actual
> + // signal handler. A bit awkward but we have to flush the read side
> + // of the pipe anyway.
> + // Failure to flush can lead to repetitive signals from QSocketNotifier
I don't find this awkward. You're reacting to a pipe write, so that seems like the right way to get the information that you want to react to.
> core.cpp:103
> + write(signalPipeWrite, &sig, sizeof(sig));
> + }
> +}
Maybe you can add an else branch where you re-raise the signal with the default handler.
REPOSITORY
R32 KDevelop
REVISION DETAIL
https://phabricator.kde.org/D16218
To: rjvbb, #kdevelop, kfunk, aaronpuchert
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/20181020/bcfc7aa4/attachment-0001.html>
More information about the KDevelop-devel
mailing list