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


Reply via email to