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:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121009
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:13 jinmei]:
 > I'm releasing the ticket for now as we excluded it from the current
 > sprint.  I'm dumping the review comments for the part of the code
 > I've covered so far:

 Is it OK to return it to you now?

 > - It's (now) probably better to avoid 'using namespace std' because
 >   this space is getting larger with C++ 0x11, increasing the risk of
 >   name collisions.

 I don't know, we may want to explicitly ask the compiler for the old
 standard
 by some `--std=iso-cpp` or whatever it is. Then it should not give us more
 things in the namespace. But I'm not really against using more concrete
 use
 statements.

 > - Mutex constructor: may not be a big deal, but you should be able to
 >   avoid using auto_ptr if you move mutex_init inside the Impl class
 >   constructor.

 This goes against the way I think about the impl class. I consider it
 being a
 data-only, so such complicated initialization doesn't belong there. Also,
 having the initialization there and everything else outside seems strange
 and
 inconsistent. The overhead for the `auto_ptr` should be small (and it's
 during
 initialization only).

 > - Mutex destructor: the last `if` doesn't seem to be possible.  If the
 >   lock is acquired at the point of the destructor,
 >   pthread_mutex_destroy() would fail.

 It should not be possible, but on my system, the `pthread_mutex_destroy`
 did
 not return error in that case (maybe it fails only when other threads wait
 for
 the lock, or something, I don't know). That is the reason I added this
 check
 there. I added a comment about it.

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