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

BIND 10 Development do-not-reply at isc.org
Fri Sep 7 08:02:11 UTC 2012


#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 vorner):

 Hello

 Just a quick reply without code update (I'm going away for vacation too).

 Replying to [comment:9 jinmei]:
 > - 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 know. Probably not now, but we may need it soon or later. And as
 the
 extra work is really small (just a condition in the constructor changing
 the
 attributes), I thought I just add it for completeness, so the interface
 won't
 need an update soon.

 > - 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 have no big preference. The performance-aimed build might have turned
 off
 both kinds of checks. I went with exceptions simply for easier testing and
 nicer error messages. Do you think it should be switched to asserts?

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


More information about the bind10-tickets mailing list