rm5248 commented on a change in pull request #68:
URL: https://github.com/apache/logging-log4cxx/pull/68#discussion_r697925078
##########
File path: src/main/cpp/threadutility.cpp
##########
@@ -44,19 +50,23 @@ void ThreadUtility::configureFuncs( ThreadStartPre
pre_start,
void ThreadUtility::preThreadBlockSignals(){
#if LOG4CXX_HAS_PTHREAD_SIGMASK
+ m_priv->creation_mutex.lock();
Review comment:
> (OTOH .. .I'm still not sure if this configurabiity/complixty is
really needed; Possibly it would be enough to block the signals unconditionally
when log4cxx starts a thread? I currently cant think of an usecase where a user
would not want that log4cxx just blocks the signals. (Please explain; I'm
obviously missing why you think it necessary)..)
My general philosophy is that sane defaults should be acceptable >90% of the
time, but there are some instances where you might want to customize this for
whatever reason. Hence the single-line call to ThreadUtility::configure to set
various default configurations, while still allowing the end-user to customize.
It's unlikely, but users could run on an OS that uses some sort of threading
implementation that doesn't use pthreads, but still needs to do something
before the thread starts.
Part of the 'naming threads' as well is that there are some systems where
you can name threads and some systems where you can't - Linux is
[pthread_setname_np](https://man7.org/linux/man-pages/man3/pthread_setname_np.3.html),
BSD may be
[pthread_set_name_np](https://www.freebsd.org/cgi/man.cgi?query=pthread_set_name_np),
and OSX uses pthread_setname_np but only [in the current
thread](https://opensource.apple.com/source/libpthread/libpthread-301.30.1/pthread/pthread.h.auto.html).
I don't particularly care if the blocking of signals is off or on by
default, as long as there is a way to change it. On by default probably makes
the most sense.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
