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

[Thiago Macieira]

On Monday, 15 October 2018 06:34:55 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > You were complaining that pipes are too costly. Ok, so get your OS vendor
> > to create an equivalent to Linux's eventfd()
> 
> Sure. Dear Apple (FreeBSD), please implement eventfd() (and a bunch of other
> Linux features because they make Linux so much better).

I wasn't joking. The Unix systems often copy neat features from one another 
when one innovates ahead of the others. I have a pending patch for Linux 
copying OpenBSD's O_NOSIGPIPE option but I have yet to finish it.

> > Do you realise that the cost of starting a thread is much higher than the
> > cost of a pipe? Not to mention that using QThread will create a pipe
> > anyway, so you'd need to drop down to low-level primitives (pthread,
> > Win32) to get away from it.
> 
> OK, that's an argument. I tried to figure that out and didn't see evidence
> that QThread *always* creates a pipe. Pity but thanks for confirming.

It's not QThread itself, it's the event dispatcher. Either 
QEventDispatcherUNIX, QEventDispatcherGlib or, on a Mac, 
QEventDispatcherCoreFoundation. But looking at the sources, it seems that the 
event dispatcher is created on-demand by the first QEventLoop or by calling 
exec(), so the file descriptor won't be opened until then.

> > You could pre-allocate the event before the signal and then you can
> > transfer ownership. But postEvent() still needs to manage a queue and
> > that may need to
> Exactly, which is what I realised when I saw it locking a mutex.

Right, it also locks a mutex, which is also why it could deadlock.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center