I will take a look at reworking the
On 08/22/10 10:09 AM, masarati@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.