Return to Answer

• I missed the destructor, meaning an fd leak (not a problem, as my handlers live the length of the program), but if I implemented one, it would be shorter - just the two close calls.

• I always avoid qFatal() and Q_ASSERT (in my applications, it's better to manage without the handler than to exit). I'm playing fast and loose with qWarning() inside the signal handler (but at that point, we're in trouble anyway, if we've lost the reader). I did find it helpful to show the error indication in the warning messages when errno has been set.

• You've found a value _NSIG for the range of signals you support. I couldn't find it documented; is that just an artefact of your particular <signal.h>?

• I also wrote a QTest unit test:

    void raiseSignal_USR1()
    {
        UnixSignalHandler handler(SIGUSR1);
  
        QSignalSpy spy(&handler, SIGNAL(raised()));
  
        QVERIFY(spy.isValid());
        QVERIFY(spy.isEmpty());
  
        ::raise(SIGUSR1);
        QVERIFY(spy.wait());
    }
  

• I missed the destructor, meaning an fd leak (not a problem, as my handlers live the length of the program), but if I implemented one, it would be shorter - just the two close calls (QPointer is automatically reset to nullptr when the object is deleted, so the handler array looks after itself).

• I always avoid qFatal() and Q_ASSERT (in my applications, it's better to manage without the handler than to exit). I'm playing fast and loose with qWarning() inside the signal handler (but at that point, we're in trouble anyway, if we've lost the reader). I did find it helpful to show the error indication in the warning messages when errno has been set.

• You've found a value _NSIG for the range of signals you support. I couldn't find it documented; is that just an artefact of your particular <signal.h>?

• I also wrote a QTest unit test:

    void raiseSignal_USR1()
    {
        UnixSignalHandler handler(SIGUSR1);
  
        QSignalSpy spy(&handler, SIGNAL(raised()));
  
        QVERIFY(spy.isValid());
        QVERIFY(spy.isEmpty());
  
        ::raise(SIGUSR1);
        QVERIFY(spy.wait());
    }
  

• I missed the destructor, meaning an fd leak (not a problem, as my handlers live the length of the program), but if I implemented one, it would be shorter - just the two close calls and a single write to handler.

• I always avoid qFatal() and Q_ASSERT (in my applications, it's better to manage without the handler than to exit). I'm playing fast and loose with qWarning() inside the signal handler (but at that point, we're in trouble anyway, if we've lost the reader). I did find it helpful to show the error indication in the warning messages when errno has been set.

• You've found a value _NSIG for the range of signals you support. I couldn't find it documented; is that just an artefact of your particular <signal.h>?

• I also wrote a QTest unit test:

    void raiseSignal_USR1()
    {
        UnixSignalHandler handler(SIGUSR1);
  
        QSignalSpy spy(&handler, SIGNAL(raised()));
  
        QVERIFY(spy.isValid());
        QVERIFY(spy.isEmpty());
  
        ::raise(SIGUSR1);
        QVERIFY(spy.wait());
    }
  

• QSocketNotifier can be forward-declared in the header; it needs to be a complete type only in the implementation.
• Re-reading, I see that you also use a file-per-signal (but not a QObject per signal). We can both save on fds by multiplexing the signal number as the data sent across the pipe.

• I missed the destructor, meaning an fd leak (not a problem, as my handlers live the length of the program), but if I implemented one, it would be shorter - just the two close calls.

• I always avoid qFatal() and Q_ASSERT (in my applications, it's better to manage without the handler than to exit). I'm playing fast and loose with qWarning() inside the signal handler (but at that point, we're in trouble anyway, if we've lost the reader). I did find it helpful to show the error indication in the warning messages when errno has been set.

• You've found a value _NSIG for the range of signals you support. I couldn't find it documented; is that just an artefact of your particular <signal.h>?

• I also wrote a QTest unit test:

    void raiseSignal_USR1()
    {
        UnixSignalHandler handler(SIGUSR1);
  
        QSignalSpy spy(&handler, SIGNAL(raised()));
  
        QVERIFY(spy.isValid());
        QVERIFY(spy.isEmpty());
  
        ::raise(SIGUSR1);
        QVERIFY(spy.wait());
    }
  

• QSocketNotifier can be forward-declared in the header; it needs to be a complete type only in the implementation. My implementation doesn't need to bring <signal.h> into the header, but I think you need it for the _NSIG constant.
• Re-reading, I see that you also use a file-per-signal (but not a QObject per signal). We can both save on fds by multiplexing the signal number as the data sent across the pipe.

Other differences (apart from the one/many signals per handler):

• I missed the destructor, meaning an fd leak (not a problem, as my handlers live the length of the program), but if I implemented one, it would be shorter - just the two close calls and a single write to handler.

• I always avoid qFatal() and Q_ASSERT (in my applications, it's better to manage without the handler than to exit). I'm playing fast and loose with qWarning() inside the signal handler (but at that point, we're in trouble anyway, if we've lost the reader). I did find it helpful to show the error indication in the warning messages when errno has been set.

• You've found a value _NSIG for the range of signals you support. I couldn't find it documented; is that just an artefact of your particular <signal.h>?

• I also wrote a unit test (for QTest):

    void raiseSignal_USR1()
    {
        UnixSignalHandler handler(SIGUSR1);
  
        QSignalSpy spy(&handler, SIGNAL(raised()));
  
        QVERIFY(spy.isValid());
        QVERIFY(spy.isEmpty());
  
        ::raise(SIGUSR1);
        QVERIFY(spy.wait());
    }
  

#Other differences Apart from the one/many signals per handler, my code differs from yours in the following:

• I missed the destructor, meaning an fd leak (not a problem, as my handlers live the length of the program), but if I implemented one, it would be shorter - just the two close calls and a single write to handler.

• I always avoid qFatal() and Q_ASSERT (in my applications, it's better to manage without the handler than to exit). I'm playing fast and loose with qWarning() inside the signal handler (but at that point, we're in trouble anyway, if we've lost the reader). I did find it helpful to show the error indication in the warning messages when errno has been set.

• You've found a value _NSIG for the range of signals you support. I couldn't find it documented; is that just an artefact of your particular <signal.h>?

• I also wrote a QTest unit test:

    void raiseSignal_USR1()
    {
        UnixSignalHandler handler(SIGUSR1);
  
        QSignalSpy spy(&handler, SIGNAL(raised()));
  
        QVERIFY(spy.isValid());
        QVERIFY(spy.isEmpty());
  
        ::raise(SIGUSR1);
        QVERIFY(spy.wait());
    }
  

#Further observations

• QSocketNotifier can be forward-declared in the header; it needs to be a complete type only in the implementation.
• Re-reading, I see that you also use a file-per-signal (but not a QObject per signal). We can both save on fds by multiplexing the signal number as the data sent across the pipe.