On Wed, 2021-08-25 at 12:35 -0400, Robert Middleton wrote: > > (Disclaimer: I only briefly skimmed the PR, so I might got things wrong.) > > > > Some thoughts: > > - I would not impose on applications should handle signals. This could > > be a mayor annoyance, especially if applications needs being changed of > > that > > (this refering to the docs about signalfd etc.) > > My objective is to not define how applications should handle signals, > the documentation is really in terms of "here's a way you can handle > signals better." That should be more clear though, so I can update > that.
Thanks for the clarifiaction; I indeed understood it that users of the library needs to use the mentioned mechanism instead. (A documentation how to use signals in general felt for me a bit out of scope for a library about logging... Maybe that contributed to my confusion.) > > - A question: does log4cxx use signals of its own? > > If not, I would use the approach to block all signals before pthread_create() > > and then restore them afterwards. > > > > Log4cxx does not use any signals on its own, so the question is should > we do this automatically or not? If you're using signalfd or > something similar, there's no need to block signals before a thread > starts, as it bypasses the issue at that point. The problem is if you don't. There a quite a few ways to handle signals, and liblog4cxx should not get in they way of those... You can even combine those methods, to make it even more complicated... For example, my mentioned §DAYJOB app uses signal handler for "fatal" signals like SIGSEV, SIGABORT and so on where I want to get an backtrace when it happens, but for users I use a dedicated signal handler thread (eg. SIGUSR1), using sig_wait() in my case... So what do to? Its actually not so easy to answer... My instict would say: get the spawned threads out of the way, in terms of signals. That means before starting the threads blocking all signals using pthread_sigmask(), spawn the thread, and then restore the previous signals set. This way, the signal handling should be "unchanged" for the rest of the application, regardless which method the application use to tackle signals. Anhother approach could be to document the issue and let the user do the stuff themselves, by providing them a hook for before and after pthread_create() or some callbacks (I think this is the approach the PR takes), with possibly being the default implmentatino the pthread_sigmask* dance from above (a default would help to keep ABI changes minimal)... (However, at the moment I'd not see really why it would be necessary to let the user have this complexity.) (* I've seen in the PR the pthread_Sigmask thing, however IIRC it fails to restore the previous signal set. ) Cheers, -- tobi