BIND 10 #2931: Receiving notifications, python part

BIND 10 Development do-not-reply at isc.org
Thu Jul 4 08:53:16 UTC 2013


#2931: Receiving notifications, python part
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:
                Type:  task          |  vorner
            Priority:  high          |                       Status:
           Component:  Inter-module  |  closed
  communication                      |                    Milestone:
            Keywords:                |  Sprint-20130709
           Sensitive:  0             |                   Resolution:
         Sub-Project:  Core          |  complete
Estimated Difficulty:  5             |                 CVSS Scoring:
         Total Hours:  3.29          |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * status:  reviewing => closed
 * totalhours:  0 => 3.29
 * resolution:   => complete


Comment:

 Hello

 Replying to [comment:10 pselkirk]:
 > In the department of philosophy, one could argue (as you have) that
 unsubscribing twice with the same ID is an error, and deserves to have an
 exception raised. On the other hand, one could argue that the end result
 is what matters - the callback is definitely unsubscribed. At least the
 action is clearly defined and tested.

 Well, I think that the end result would be the only thing that matters in
 case the unsubscribe was based on some meaningful parameter, like the
 notification group only.

 However, as it is some opaque handle, there's no reasonable way the
 application could try to unsubscribe something that doesn't exist and
 still being correct. Therefore the exception is more like an early warning
 that something is wrong.

 Also, it's easier that way in the code.

 > The other thing that caught my eye is that callbacks are called in ID
 order, and you actually sort them to enforce that. Is there any real
 benefit to sorting? I'm not objecting, just curious.

 I don't have an concrete example right now, but I often find that the
 well-defined order (no matter what it is) is important from time to time.
 But even for reproducing bugs (like crashes), it is better to behave the
 same every time. The order of dict can vary between different runs of the
 same python interpreter.

 There could probably be better ways in terms of performance than sorting
 to ensure that, but I don't think there'll be many callbacks subscribed,
 and the notifications won't be that often to matter.

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


More information about the bind10-tickets mailing list