BIND 10 #2211: update the data source reconfigure command so it uses thread

[BIND 10 Development]

#2211: update the data source reconfigure command so it uses thread
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121106
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:18 jinmei]:
 > I really don't understand it if you mean this one is "extreme" or
 > complicated:
 > {{{#!cpp
 >         {
 >             typename MutexType::Locker locker(queue_mutex_);
 >             command_queue_.push_back(
 >                 datasrc_clientmgr_internal::Command(command, arg));
 >         }
 >         cond_.signal();
 > }}}
 > while this is not:
 > {{{#!cpp
 >         {
 >             typename MutexType::Locker locker(queue_mutex_);
 >             command_queue_.push_back(
 >                 datasrc_clientmgr_internal::Command(command, arg));
 >             cond_.signal();
 >         }
 > }}}
 >
 > I don't mind changing the former to the latter, but since I may simply
 > misunderstand you, I still didn't change that.

 Whenever there is a block that is neither a function or if or a cycle, I
 find it unusual. But let it be.

 > Ah, okay, you're right in that sense.  For now, however, I keep the
 > current code because efficiency in queue operation isn't a big issue
 > here anyway, and because we may want the pop behavior in future
 > extensions.

 OK. It's probably marginal.

 > > I think it would be better to put abort in there at least for now, and
 have
 > > some better error handling deferred for a later ticket (but I don't
 know what
 > > better should be done).
 >
 > Okay, changed.  I'll create a separate topic for this issue.

 Can you change the LOG_ERROR to LOG_FATAL there, if we are going to abort
 for that reason?

 Otherwise the code looks good, so please merge. Or you might want to wait
 a
 short while, until my local test run finishes, but I don't expect it to
 break,
 there were no changes that should cause that.

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