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

[Thiago Macieira]

On Wednesday, 10 October 2018 00:50:10 PDT René J. V. Bertin wrote:
> Thiago Macieira wrote:
> > You can call _exit. You can't call much else. You can only call the
> > functions listed in this man page from a signal handler:
> > http://man7.org/linux/man-pages/man7/signal-safety.7.html
> > 
> > NEVER allocate memory and NEVER lock a mutex in a signal handler.
> 
> So you are basically saying that KDevelop is doing it all wrong and that
> it's purely by chance that this works (when the X server is responsive)?
> 
> https://github.com/KDE/kdevelop/blob/master/kdevplatform/shell/core.cpp#L54
> 
> (not looking to point fingers, just to know if there's room for improvement)

Yes. That code is a timebomb waiting to go off. Or maybe a better metaphor is 
a Russian roulette, since it depends on what the other threads are doing, 
meaning you can be lucky most of the time. The qCDebug and 
QApplication::closeAllWindows allocate memory, so they can deadlock inside 
malloc(). QCoreApplication::quit() doesn't, but it's not async-signal safe 
either.

> And a complementary question: why does  QXcbConnection::processXcbEvents()
> call exit() when the X server (probably) died, if that's not supposed to
> work?

It's not supposed to, but at that point it's the least of our worries. The 
application no longer has a GUI, so it can't display anything anyway for the 
user. If it crashes, that's fine: it'll just be one more core file that your 
system will capture, after X's. The worst case scenario is if it deadlocks, 
but systemd will probably kill it anyway as the user session is exiting.

> I wonder if that explains why I sometimes see evidence of Qt applications
> that crashed after an X server went down.

It could.

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