BIND 10 #2198: make sure InterprocessSyncLocker is thread safe

BIND 10 Development do-not-reply at isc.org
Wed Oct 17 04:07:45 UTC 2012


#2198: make sure InterprocessSyncLocker is thread safe
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  reopened
                       Type:         |             Milestone:
  defect                             |  Sprint-20121023
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  Core
  logging                            |  Estimated Difficulty:  5
                   Keywords:         |           Total Hours:  3.25
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by muks):

 These issues occured during the merge to `master`:

 * On Mac OS, `-lpthread` was not being used to link to the pthreads
 library which made `pydnspp` tests fail.
 * On CentOS (and even Debian and Solaris i686), `pthread_mutex_trylock()`
 returned `EDEADLK` when a mutex was already locked in the same thread,
 which was not checked. Fedora and some other systems returned 'EBUSY'.
  * This caused a locker test's child to fail on Solaris and not return
 status to its parent.
 * On Debian i686, there was a static destruction fiasco where the `Mutex`
 and `SyncMap` inside `InterprocessSyncFile` were being destroyed before
 the logger object which used it.

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


More information about the bind10-tickets mailing list