BIND 10 #2332: define and implement wrapper interface for conditional variables

BIND 10 Development do-not-reply at isc.org
Tue Oct 9 08:33:24 UTC 2012


#2332: define and implement wrapper interface for conditional variables
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:         |  Proposed
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by vorner):

 Hello

 Replying to [comment:2 jinmei]:
 > I meant, by "non trivial extensions," we'd need to do something like
 > ugly friend declaration:-)  And, IMO, when `friend` seems to be the
 > choice in the first impression, we should generally think about
 > whether there can be a cleaner design.  For example, we should check
 > what kind of abstraction boost thread is using and should learn from
 > it, not just starting from what we have as a given condition.

 I've seen different opinions on friend declarations, some saying it is
 wrong
 the same way as goto is wrong (which is questionable at best as well). The
 other side says that a well-used friend declaration can keep you public
 interface clean and simple while still allowing cooperation of related
 classes.

 I somewhat agree with the second group and I think this is exactly the
 case. I
 think the code I posted looks reasonably readable. It doesn't need
 addition of
 any strange „getOSDependantMutexDescriptor()“ method to the public
 interface.
 And you can't leave the mutex locked and walk away easily, which is, I
 think,
 very important.

 Or do you have any more error-proof interface in mind? Or more convenient
 (although, in the vicinity of threads, I'd vote for more safe than more
 convenient).

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


More information about the bind10-tickets mailing list