BIND 10 #2202: introduce a lock for the data source client in auth

[BIND 10 Development]

#2202: introduce a lock for the data source client in auth
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  UnAssigned
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  low    |  Sprint-20120918
                  Component:         |            Resolution:
  b10-auth                           |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:         |           Total Hours:  0
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 I made a few editorial/style fixes.

 I don't think I can complete or follow up with the review process
 before I go offline, so I don't own the ticket, but I'm providing some
 initial feedback.

 '''lock.h'''

 - Do we really need the recursive mode, at least right now?
 - s/locket/locker/?
 {{{#!cpp
     /// To lock a mutex, create a locket. It'll get unlocked when the
 locker
     /// is destroyed.
 }}}
 - I don't think we need to make `Locker` a friend of `Mutex`:
 {{{#!cpp
 private:
     friend class Locker;
 }}}
   (`Locker` should be able to access private members of `Mutex`)

 '''auth_srv.cc'''

 - I personally would like to avoid throwing from destructors.  While
   the end result may be the same in practice, I'd explicitly assert()
   it and let the process die, and keep the assumption on
   exception-freeness throughout the code.
 - I suspect we should hold the lock longer than this implementation
   does.  `Message` may contain `RRset`s that possibly depend on the
   current data source client, so the lock should be held at least
   until the message is cleared (a recent ticket, now in master)

 '''thread.cc'''

 - I believe in this case we can safely use static_cast:
 {{{#!cpp
         Impl* impl = reinterpret_cast<Impl*>(impl_raw);
 }}}

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