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

 Replying to [comment:7 stephen]:
 > > 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).
 >
 > You're right, there is a supposition that a 32-bit get or set is atomic.
 I'm assuming that BIND10 won't be available for 16-bit architectures
 (purely on the grounds of address space size). I'm also implicitly
 assuming that the compiler will align 32-values on 32-bit boundaries to
 allow atomic reads/writes elsewhere (although now that you've pointed it
 out, I must admit that I'm not sure that is the case in some of the modern
 64-bit architectures). But it is trivial to add a mutex specifically to
 protect those elements if needed.

 I guess 64bit architectures must have them alligned as well, because
 unalligned data access can get really slow. I'm not sure if there's any
 current architecture where 32bit integer would not act atomically, but who
 knows, in theory. What about some small arms things used in the small
 plastic boxes people call routers?

 Anyway, I'm not sure if anything bad can happen with setMaxSize when add
 is in progress. Or what optimisations might a compiler do with the code.

 > With uint32_t we know what the maximum value is and that it will be
 sufficient for our needs.  But I'm easy - we could use size_t if it is
 felt to be better.

 I'm not sure. Do we need the maximum value?

 I like to use size_t for sizes, as it is a type designed for that kind of
 thing and says what it is supposed to be. It might turn out that uint32_t
 would be too small in 5 years on 128bit architectures and people want
 large caches. And it might turn out to be slow on that kind of machine
 (but it is unlikely).

 > The string as the zone name is a place holder for now; mainly because I
 was not sure what is the best format and what operations are needed.  I'm
 also wary about using Name if we need to construct intermediate objects -
 there is a lot of processing in the constructor which we might not need.
 >
 > As to class, you are right - it could be RRclass - although that is just
 a fancy wrapper around a uint16_t.

 I know it is. But interacting with the rest of the code would be easier,
 with the same interface, now lot of conversion calls is needed even in
 test code. I guess worying about the overhead in constructor smells little
 bit as a premature optimisation. Furthermore, I think that we will have
 Name object in most cases, so we need to call toText() on it and when it
 gets out, it would need to get converted back to Name(). Now I'm checking
 that authoritative section contains the correct zone and that contains
 Name too.

 So I think using the same stuff as the rest of code is more convenient.

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