BIND 10 #347: Implement query counters in auth module

BIND 10 Development do-not-reply at isc.org
Mon Dec 27 20:35:25 UTC 2010


#347: Implement query counters in auth module
------------------------------+---------------------------------------------
      Reporter:  naokikambe   |        Owner:  y-aharen             
          Type:  enhancement  |       Status:  reviewing            
      Priority:  major        |    Milestone:  y2 12 month milestone
     Component:  b10-auth     |   Resolution:                       
      Keywords:               |    Sensitive:  0                    
Estimatedhours:  0.0          |        Hours:  0                    
      Billable:  1            |   Totalhours:  0                    
      Internal:  0            |  
------------------------------+---------------------------------------------
Changes (by jinmei):

  * owner:  jinmei => y-aharen


Comment:

 Replying to [comment:15 y-aharen]:

 '''asio_link.cc'''
 > > > >  - IntervalTimerImpl::callback()
 > > Throwing an exception in setupTimer() is fine.  I meant the assert()
 in callback(), and now the setupTimer() ensures the parameters are valid
 and it's the only place they can be set, we can safely assert() the fact
 here.  But this is just a comment; whether to re-introduce the assert() is
 up to you.
 > I see. I think it is not necessary to assert because the parameters are
 checked in setupTimer().
 >
 It's up to you, but the reason doesn't make sense to me.  With that logic
 we'd never need any assert().  assert() is to perform a run time check for
 something "that should never happen because we should have checked the
 parameters/validated the input/not modified the data, etc" in the first
 place.  But in reality humans are not perfect and make mistakes, and
 anything that should never happen will often happen.  That's why we need
 assert().

 To be clear, again, it's up to you.  After all, no one will do assert() in
 the obvious code like this:
 {{{
     int i = 0;
     ++i;
     assert(i == 1);
 }}}

 The real cases are more subtle, of course, and different developers have
 different senses of "what's obvious".  Asynchronous code logic is often
 tricky and tends to cause surprising bugs, which is why I thought
 assert()ing it may make sense.  But if you think the correctness of the
 current code is sufficiently obvious, feel free to leave the code without
 the assert().

 > If there is no problem, I will merge the branch into trunk.
 >
 I'm okay with the branch.  Please feel free to merge it.

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


More information about the bind10-tickets mailing list