I will take a look at reworking the
On 08/22/10 10:09 AM, masar...@aero.polimi.it wrote:
My concern is: can you guarantee that the occurrences of locking/unlocking
those additional mutexes, combined to the existing ones, do not result in
deadlocks? I mean: did you explicitly check all possible logical paths or
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
init.c:
#if defined(HAVE_THR)
#elif defined(HAVE_PTHREADS)
PTHREAD_MUTEX_INITIALIZER
#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.
Also, but since it's a test tool it is not a priority, slapd-mtread.c
should use libldap_r and hide thread implementation details under
OpenLDAP's portable interface.
I agree, that slapd-mtread.c still needs additional work.
[Also see first respose]. I will revise and clean this up for
the next round of code review.
Doug.
