[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Operation thread-safe
Hi,
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.
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.
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.
thanks in advance,
Indranil