Re: Operation thread-safe

[Indranil Bhattacharya <bindranil@novell.com>]

Hi Kurt,
        What about doing away with ldap_dup() /ldap_destroy () and
pushing that intelligence into the library implementation ? 
        I mean, the thread-specific data structures of ld are stored in
the TSD of a thread. Whenever any ldap api is called, it tries to get
the TSD of the calling thread. If that is NULL, it sets up one and uses
it to store and work on ld_errno, ld_matched, etc.
        As for the data structures common to all the threads, the
approach remains same as the earlier design ( i.e serializing access
using synchronization primitives ).

regards,
Indranil



On Tue, 2003-11-18 at 22:24, Kurt D. Zeilenga wrote:
> 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 
>