[Interest] proper (silent) exit in response to SIGHUP?
Thiago Macieira
thiago.macieira at intel.com
Fri Oct 12 17:46:42 CEST 2018
On Friday, 12 October 2018 00:26:44 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
>
> So I got to thinking: how Linux-specific if not exclusive are the guidelines
> you pointed me to
> (http://man7.org/linux/man-pages/man7/signal-safety.7.html)?
They're not. They're just the first link I found when googling for "signal
safe". The official list comes from POSIX.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/
V2_chap02.html#tag_15_04
> > Open a pipe or an eventfd, then install your signal handler. In that
> > signal
> > handler, write anything to the writing end or write uint64_t(1) the
> > eventfd. Create a QSocketNotifier on the reading end of the pipe or on
> > the eventfd,
> Evenfd is Linux-only AFAIK, and opening 2 file descriptors is relatively
> costly on *BSD (which have like a 256 fd per-process limit) if you also
> want to use as many QFileSystemWatchers as possible.
QFSW on BSD uses kqueue, so one fd per QFSW.
Trivia: FreeBSD has eventfd, but it's not available for FreeBSD-native
applications. It's only available for Linux ones.
> Finally: why use a QSocketNotifier that sends a signal to a slot, how is
> that different from sending the signal directly from the signal handler
> function?
If you meant "emit a signal", then it's one of the two:
a) direct connection - well, then why didn't you put the contents of your
shut down in the UNIX signal handler in the first place? There was a reason.
b) queued connection - allocates memory
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Interest
mailing list