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