[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