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:
                Type:  task          |  vorner
            Priority:  medium        |                       Status:
           Component:  shmem         |  reviewing
  manager                            |                    Milestone:
            Keywords:                |  Sprint-20130709
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  4             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by muks):

 * owner:  muks => vorner


Comment:

 Hi Michal

 Replying to [comment:14 vorner]:
 > 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.

 Now that #2854 has been merged to master, I've rebased this work on top
 of `master` branch and it is in the `trac2855_2` branch. The commits are
 identical upto this point.

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

 This has been done now. We use the same lock object in the condition
 variable. The extra locking has also been removed where unnecessary.

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

 Apparently `assertEqual` calls `assertTupleEqual` in this case
 internally. I read that `assertTupleEqual` asserts that operands are
 tuples. This may be redundant, but I've kept it as-is.

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