BIND 10 #2855: introduce a "zone builder" thread in memory manager

[BIND 10 Development]

#2855: introduce a "zone builder" thread in memory manager
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:  muks
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  shmem         |                    Milestone:
  manager                            |  Sprint-20130709
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  4             |  Feature Depending on Ticket:
         Total Hours:  0             |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => muks


Comment:

 Hello

 Replying to [comment:13 muks]:
 > Will do, but just once after #2854 is merged to `master`. I don't want
 > to merge from #2854 multiple times. In this particular case, the failing
 > testcase doesn't hurt, so we can wait until the final merge time.

 The test case may not hurt except that it's harder to run all the test
 cases to see if anything else broke or not.

 But I merged locally to perform the tests and it passed, so it's OK.

 > A condition object has a lock object associated with it. When we
 > `acquire()` on a condtiion (here using the `with` statement), the lock
 > is acquired. `wait()` releases the lock when it is called, and when it
 > returns, it re-acquires the lock.
 >
 > Our extra lock is redundant when we use the queues after acquiring on
 > the condition variable. But this is not always so. When a notification
 > unblocks `select()` and our callback is called, access to the queues
 > will be synchronized only with the lock object. It's very unlikely that
 > the builder thread will be unblocked at the same time, but it's better
 > to synchronize with a lock object.
 >
 > One thing we could do is use the same lock object for the condition
 > variable too (to avoid extra acquires in the `MemorySegmentBuilder`
 > class). But this is a minor detail.

 Such thing may deserve an explaining comment. Also, I'm little bit nervous
 about interaction of two locks and the condition variable. Could there be
 a deadlock in such case? I think there should not be, but it would be
 easier to prove in case we had only one mutex total.

 Would it be OK to change it to using just the one in the condition
 variable?

 > > What is the advantage of using this instead of just assertEqual?
 >
 > I think you missed pasting the place in code that you are referring to
 > here.

 Ah, right, I did. There are few places where you use something like this:
 {{{#!python
 self.assertTupleEqual(response, ('bad_command',))
 }}}

 My impression always was that using `assertEqual` suffices here and used
 it at many places, so I want to know if I was introducing problems.

 > I have an idea of the response format (it's a tuple and the
 > "bad_command" response was formatted as such), but this is best handled
 > in #2856 where such notification is actually used.

 OK.

 I see there's a new test about being woken up by the `x` character, so I
 think that is enough for now.

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