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-20110927
                   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

 Most of the changes look OK. Just few points:

 Replying to [comment:13 naokikambe]:
 > > Indeed the patch did contain many changes not directly or obviously
 related to the topic of the ticket. While I agree they are useful, they
 could have been potentially separated under a different ticket.
 >
 > That's right, but I'm sorry for the confusion. If the separation is
 still required, I will do that.

 No, don't do the splitting now, it would only produce more confusion.

 > Because it doesn't need to do so. It doesn't need to close the httpd
 socket if no http socket is opened yet. Normally it is opened by the
 open_httpd() method in __init__(). It doesn't need to reopen the existent
 http socket unless the listen_on config is changed. Please see also
 https://lists.isc.org/mailman/htdig/bind10-dev/2011-August/002582.html.

 Ah, right. This one is the shutdown part. I looked wrong the first time.

 > >  * Is this really needed? Isn't it enough for the garbage collector to
 claim and close the socket? (your way might be cleaner anyway, but I'm
 interested)
 >
 > If it successfully finds the available address and port, it needs to
 close it for the reuse before it returns. I don't think the garbage
 collector might do that enough on any environment. Is that correct?

 Right, I see. Well, in the case of success, it could be without the
 finally, in theory. And the garbage collector could use reference counts
 to reclaim most of the objects right away (most of the objects don't
 contain cycles), but we can't really rely on that. But as I said, this is
 just out of interest, not because your code would have a problem.

 > >  * Talking about `is_ipv6_enabled` - why isn't `socket.has_ipv6`
 enough?
 >
 > Because the value was True even though I disabled IPv6 config on my
 environment.

 OK. Could you comment on it in the code, why the has_ipv6 isn't enough?

 > >  * 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?

 Thank you

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