BIND 10 #356: Resolver address database

[BIND 10 Development]

#356: Resolver address database
-------------------------------+--------------------------------------------
      Reporter:  stephen       |        Owner:  stephen  
          Type:  enhancement   |       Status:  reviewing
      Priority:  major         |    Milestone:           
     Component:  Unclassified  |   Resolution:           
      Keywords:                |    Sensitive:  0        
Estimatedhours:  0.0           |        Hours:  0        
      Billable:  1             |   Totalhours:  0        
      Internal:  0             |  
-------------------------------+--------------------------------------------

Comment(by vorner):

 As I start #408, I read the code and documentation
 (NameserverAddressStoreDesign) and I would like to point few things out,
 even when I'm not reviewing this.

 The hash tables has mutex on each cell, to minimise the locking
 contention. However, the LRU has only one global mutex and each lookup in
 the hash table will result in one update of the LRU as well, so it seems
 the many mutexes on the hash tables are useless, as the threads will
 collide in the LRU. Or is there a plan to address this somehow?

 I'm little bit concerned about locking of the data (zone entry and
 nameserver entry). Currently it seems there's not enough of it. For
 example, NameserverEntry::getExpiration does not lock, but the expiration_
 may change, when new referral data come. With lru_data, size, getMaxSize
 and setMaxSize assume that uint32_t are atomic types, which is not the
 case (or, is not guaranteed to be the case in all architectures). Speaking
 about the sizes, why we use uint32_t? Shouldn't we use size_t?

 Why we use string as the zone name and uint16_t as the class type?
 Shouldn't we use isc::dns::Name and isc::dns::RRClass?

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