On lundi 4 décembre 2017 17:04:25 CET Thiago Macieira wrote: > On Monday, 4 December 2017 00:26:55 PST David Faure wrote: > > > Or do you fork a child at that point? fork from inside a signal handler > > > is > > > an incredibly bad idea, don't do it. > > > > Well, I guess that's why it's the fallback from the main strategy which is > > "ask kdeinit to restart that application" (even if it doesn't provide a > > kdeinit module). But kdeinit might not be running, outside plasma > > workspace. > > > > This has always been like that, it goes back to 2006 (Luboš), it was > > discussed with you > > https://marc.info/?l=kde-core-devel&m=113699766611213&w=2 ("There's still > > a > > fallback to use fork() in case using kdeinit fails for any reason.") > > Well, I've learnt a lot in the last 11 years. > > forking inside a signal handler is a bad idea because it may deadlock. If > the crash happens while glibc holds some mutexes relating to > pthread_atfork, then you'll have a problem.
I see. But how should one implement a crash handler that autorestarts an app, then, in a "standalone application" use case, i.e. no kdeinit or other daemon running in the background? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5