BIND 10 #2202: introduce a lock for the data source client in auth

[BIND 10 Development]

#2202: introduce a lock for the data source client in auth
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:
  jinmei                             |                Status:  new
                       Type:  task   |             Milestone:  Next-Sprint-
                   Priority:         |  Proposed
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  background zone loading            |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> A subtask of #2201.
>
> Basically, anyone (within auth) who calls getClientList() or
> setClientList() needs to acquire the lock.  But until we actually
> needs it in multiple thread, I suggest we only acquire/release the
> lock in processNormalQuery().  Note that the lock must be held until
> the rendering is completed.  Also care for exception safety.
>
> Also, check its performance impact using query_bench on a couple of
> different platforms.
>
> Open question: I'm not sure whether to use boost's thread support or
> pthread (or some lower level C API) directly.  Boost provides nice
> features such as exception safety, but once we enable Boost thread
> it enables other thread-related overhead throughout the library.
> Right now I'm inclined to choose not to use Boost features (and
> explicitly disable threads by defining BOOST_DISABLE_THREADS at the
> top level), but this is a subject of project-wide discussion.

New description:

 A subtask of #2201.

 Basically, anyone (within auth) who calls getClientList() or
 setClientList() needs to acquire the lock.  But until we actually
 needs it in multiple thread, I suggest we only acquire/release the
 lock in processNormalQuery().  Note that the lock must be held until
 the rendering is completed.  Also care for exception safety.

 Also, check its performance impact using query_bench on a couple of
 different platforms. (note: we'll need #2216 for this)

 Open question: I'm not sure whether to use boost's thread support or
 pthread (or some lower level C API) directly.  Boost provides nice
 features such as exception safety, but once we enable Boost thread
 it enables other thread-related overhead throughout the library.
 Right now I'm inclined to choose not to use Boost features (and
 explicitly disable threads by defining BOOST_DISABLE_THREADS at the
 top level), but this is a subject of project-wide discussion.

--

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