[Interest] proper (silent) exit in response to SIGHUP?
Thiago Macieira
thiago.macieira at intel.com
Mon Oct 8 21:50:20 CEST 2018
On Monday, 8 October 2018 12:45:19 PDT Giuseppe D'Angelo via Interest wrote:
> Il 08/10/2018 09:50, René J.V. Bertin ha scritto:
> > 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?
> Given we're already in Linux-specific domain, also signalfd(2) comes
> into mind.
Please don't use that, it's a worse solution.
signalfd(2) requires that the UNIX signal in question be blocked in all
threads, otherwise UNIX signal handlers take precedence over the signalfd. You
can accomplish that by:
a) blocking the signal in the main thread before any other threads are
started (this includes the XCB event thread, so before QApplication)
b) ensuring no thread unblocks the signal, so you must know what each and
every library does, internally
Usually you can use signalfd from the application code, but it's not an
acceptable solution for a library. That's why we don't use it in Qt. But even
for applications, it's not meant for complex, multi-threaded ones, just like
timerfd(2) is often a worse solution that calculating your own timeouts.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Interest
mailing list