[Interest] proper (silent) exit in response to SIGHUP?

René J.V. Bertin rjvbertin at gmail.com
Mon Oct 8 09:50:50 CEST 2018


Thiago Macieira wrote:

That sounds real easy indeed ;)

> Create a QSocketNotifier on the reading end of the pipe or on the eventfd,
> connect its activation signal to a slot that does what you want.

What is the purpose of the pipe/eventfd detour? Can't I just call a function or signal a slot directly?

> Exiting with exit() is not expected to work with Qt. Normal exit must return
> from main(), so you should simply ask the QCoreApplication main event loop to
> exit (quit() slot).

A KDE dev told me a SIGHUP should already work (contrary to my experience). So I tried it on a complex app running locally and it turns out that it indeed went through its regular shut-down cycle. Including unsaved file alerts.

> But if you wanted that, you wouldn't need to add a signal handler, since
> SIGHUP's default behaviour is to terminate the application.

True, though I'm not sure how picky one can be if you want to avoid attempts at interaction with the user. I'd expect that calling the dtor on an instance of a document class holding an unsaved document would trigger "do you want to save this file" dialog. Dtors in the XCB plugin could well try to close down properly, making calls that block if the remote server has become unavailable.

This sort of YMMV is why I didn't wonder aloud why Qt doesn't attempt to catch SIGHUP itself, to invoke QCoreApplication::quit.

R.



More information about the Interest mailing list