Re: Operation thread-safe

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

At 06:05 AM 11/17/2003, root wrote:
>    I am an engineer in Novell, Bangalore working on making Novell's
>c-ldap sdk ( which, I believe, is sourced from the OpenLdap's c-ldap sdk
>) operation thread-safe.I needed some help in that regard.

Yes.  See Novell website for details.  :-)

>     I went through the draft in
>(http://www.watersprings.org/pub/id/draft-zeilenga-ldap-c-api-concurrency-00.txt) and also looked up Mozilla's c-ldap sdk; that claims to be thread-safe. Since, I wanted to have "Different threads within the same process; using the same ld"; I guessed that necessitated a operation-thread safe implementation.
>
>    My design essentially follows what you have already said in the
>draft. Basically, I have classified the data structures within the ldap
>handle ( ld ) into ones which should be common to all threads( for ex;
>ld->ld_defconn) ; and others(for ex ; ld->ld_errno ) which should be
>thread specific. Access to the common data structures is serialized
>using wrapper thread routines implemented within the library ( libldap_r
>). As for the thread-specific data structures; there is a copy for each
>thread. 
>    When the api programmer calls ldap_dup(); the library creates a copy
>of the existing ld. Each copy of the ld contains personal copies of the
>thread-specific data structures; and pointers to the common data
>structures. Therafter, the thread continues to use this copy; until it
>destroys it using ldap_destroy(). ldap_destroy() does not free the
>common data structures; but ldap_unbind() does.
>    Since, ld->ld_errno is thread-specific; the design also implements
>the "Ldap C Api error reporting extension".
>
>Just wanted to know, whether this design goes well with what you had in
>mind when you wrote the above draft.

Yes.  Your design appears to be in line with my draft.

>Also, I needed a review about the classification of the data-structures
>within ld into common/thread-specific.
>I have kept ld_errno, ld_error , ld_matched, ld_options(almost) and
>ld_lberoptions(almost) as thred-specific. Everything else, including
>ld_responses and ld_requests are common to all the threads.

The tricky part is ldap_result(3) handling....

Kurt