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

 About the failing test, the current version of #2854 already fixed that.
 Can you merge it, please?

 What does it mean in python to acquire a conditional variable? Does the
 conditional variable work as mutex as well? If so, is there any reason to
 have yet another mutex separately? If not, why should this be safe?

 {{{#!python
                 while len(self._command_queue) == 0:
                     self._cv.wait()
 }}}

 How does the quiting of the thread correlate the fact we don't notify the
 main thread? How does the main thread know it should join the failed
 thread? This way, it will probably just sit there and keep filling the
 command queue, without ever doing anything real.

 What is the advantage of using this instead of just assertEqual?

 The `test_bad_command` has copy-pasted comments that are not true, they
 are from the `test_shutdown`. This is both for the part that says it'll
 put shutdown there and for the one saying the response queue should be
 empty.

 Regarding the notifications I don't think there's any need for format as
 such. The socket pair is needed just for one thing ‒ waking up the select.
 This is quite common pattern and is done like this:
  • Write a byte of data to the writing end (non-blocking, if it would
 block, there's already data, so no need to add more).
  • Once select is woken up, read everything from there. The data in the
 socket have no meaning, it's just a signal.
  • Check the items in the queue and handle them.

 So, while we don't know the format of data in the response queue, we don't
 need that one for the implementation of the notifications themselves. It
 would be similar as with the shutdown command ‒ something that would pick
 up all elements in the queue, run through them and have dummy handler for
 one.

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