Re: Multi-threaded slapd on AIX 4.2.1

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 05:53 PM 6/30/99 +0200, Frédéric Poels wrote:
>Hello!
>
>Phew! I hope I finally post this message to the right group...
>I have applied a few patches to the latest openldap "stable" release to
>compile a multi-threaded slapd on AIX 4.2.1. Here they are :

I'm not familiar with AIX specifics...

>1) Threads need a special setup on AIX 4.2.1 so the cc_r compiler must be
>used instead of cc :
>export CC=cc_r
>./configure --my-options

What threading features did configure detect?  Specifically,
did it detect Pthread draft4 or final compatible threading?
Did it detect sched_yield and/or pthread_yield()?
If final was detected, does your system have sched_yield?
Is the detection consistent with AIX's threading implementation?

I can infer some of this from your patch... but the above would
be useful in general.

>
>2) By default, threads are created "detached" on AIX 4.2.1. To create them
>"undetached" (or "joinable"), an explicit parameter must be passed to
>pthread_create :

Yiks!  This will break most every thread application that relies on
threads being joinable by default (as required by the standard).
Looks like it's fixed in AIX 4.3.

I also noticed that you used a flag PTHREAD_CREATE_UNDETACHED.
Does AIX not have PTHREAD_CREATE_JOINABLE?

Or, is this a problem with the pthread_create call using NULL
instead of the Pthread draft4 pthread_attr_default macro.  If
your system was detected as draft4, I'd be curious to whether
or not using pthread_attribute_default would provide joinable
threads.   Our devel code uses pthread_attribute_default when
draft4 is detected.

>The resulting slapd (with the gdbm backend) runs fine and gives a good
>response time but is subject to huge memory leaks. The same server compiled
>on a Linux box does not appear to grow (with the gdbm backend again).
>Neither does the same server compiled on AIX without threads support. Can
>anybody help?

I suspect pthread_detach() is not detaching the threads...
resulting in significant resource leakage.