I will take a look at reworking the
On 08/22/10 10:09 AM, masarati(a)aero.polimi.it wrote:
>> My concern is: can you guarantee that the occurrences of
>> those additional mutexes, combined to the existing ones, do not result
>> deadlocks? I mean: did you explicitly check all possible logical paths
>> so, or take measures to avoid this possibility?
> Another mostly "style" comment: I think you shouldn't be polluting
> libldap's space with thread implementation specific details, like
> #if defined(HAVE_THR)
> #elif defined(HAVE_PTHREADS)
> #if !(defined(HAVE_THR) || defined(HAVE_PTHREADS))
> and so. I understand PTHREAD_MUTEX_INITIALIZER is handy, but the whole
> thing should remain confined in libldap_r specific files.
I will take a look at reworking this for the next round of code review.
#define LDAP_PVT_MUTEX_INITIALIZER DEFAULTMUTEX
#define LDAP_PVT_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER
#define LDAP_PVT_MUTEX_INITIALIZER NULL
then use LDAP_PVT_MUTEX_INITIALIZER in code; you could then add a
ldap_pvt_thread_mutex_init_if(mutex) that assumes mutex was initialized
with LDAP_PVT_MUTEX_INITIALIZER; for THR and PTHREADS this call should be
empty, while in the remaining cases it would call
ldap_pvt_thread_mutex_init() only if mutex is not equal to
Also, I get some nasty warnings from other parts of the code that
(admittedly incorrectly) include ldap-int.h because
LDAP_PVT_THREAD_ASSERT_MUTEX_OWNER() is being redefined. I suggest that
instead of #defining it if LDAP_R_COMPILE is not defined, you rather
#define LDAP_ASSERT_MUTEX_OWNER(mutex) \
LDAP_PVT_THREAD_ASSERT_MUTEX_OWNER( mutex )
so you avoid mixing LDAP_PVT_THREAD_* and LDAP_* macros.