[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