BIND 10 #1175: find another solution to synchronize between threads used in unittests for stats

[BIND 10 Development]

#1175: find another solution to synchronize between threads used in unittests for
stats
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  naokikambe
  naokikambe                         |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20111011
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  statistics                         |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => naokikambe


Comment:

 Hello

 Replying to [comment:16 naokikambe]:
 > > OK. Could you comment on it in the code, why the has_ipv6 isn't
 enough?
 >
 > I revised the comment. Please see git
 f9142f0bcd6faff5def205263ff91ce28d5dbe79.

 Thanks

 > > > >  * This looks scary. I think this would deserve a comment why the
 retries are necessary.
 > > >
 > > > I revised the comment but this retry may not be so important. Please
 see git cef9bd05810891bb4d0b44f0dc3ad47ee8161784.
 > >
 > > Well, the comment says a little bit more than in the original, but it
 still states the obvious or something easy to guess from the code. What I
 mean by "why is it necessary“ is the situation in which the timeout can
 happen. Do we need to wait for the other end to start? Or is there a
 different reason why it might fail?
 >
 > Sorry, I don't know that reason exactly. But in my environment one-time
 trial was often failed but now there is no failure. I don't know that is
 due to some environment or some timing. In order to exactly know there is
 no necessity, we may need to remove that retrying code and then test it
 again on buildbot. I committed the code without the retry at git
 474c0b02bb1d978fbb169aa9d0121c873019e31d. This branch is ready for
 buildbot test but now the master branch doesn't seem to be stable. I'll
 wait it.

 Hmm. If it turns out it is not needed, then it's OK. But if it is, I'd be
 very interested in the reason for it. It might be harmless or it might be
 hiding some other problem which might need fixing.

 Maybe see what comes from the buildbots and if it is needed, return the
 retries back, put a comment like

 {{{
 # FIXME: We don't really know why this is needed and it should be
 investigated.
 }}}

 merge it and create a ticket to investigate it?

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