[Interest] proper (silent) exit in response to SIGHUP?
thiago.macieira at intel.com
Mon Oct 15 17:59:15 CEST 2018
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
More information about the Interest