BIND 10 #2399: make Logger::getLoggerPtr() thread safe

[BIND 10 Development]

#2399: make Logger::getLoggerPtr() thread safe
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:         |             Milestone:  Next-Sprint-
  defect                             |  Proposed
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  DNS
  logging                            |  Estimated Difficulty:  0
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:1 vorner]:
 > And how do you initialize the mutex without the static initialization
 fiasco in
 > a thread-safe manner?

 As briefly explained in the description, in initLogger().  In fact,
 this is *the* trick with which avoid all sorts of initialization
 fiasco in the log library (it heavily relies on singleton/static
 things.  It's API contract basis (on the assumption that the
 application calls initLogger() before doing anything with log library)
 and in that sense not a perfect solution in theory, but since we
 already rely on it I don't see a reason for not using this for this
 case too.

 > One way to solve the problem could be to make sure the logging is
 initialized
 > before we start the thread.
 >
 > Or is it so that there are many Logger objects, each of them having this
 > problem? Then we probably would have to do it the combined way ‒ have
 single
 > global mutex and make sure it is initialized in the non-threaded startup
 of
 > application dynamically.

 There are many (at least multiple for normal apps) logger objects, and
 its full initialization is delayed until it's used first time via
 LOG_INFO() etc.  And, actually, if I understand it correctly, the
 "combined way" is exactly what I suggested here.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2399#comment:2>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development