Re: Operation thread-safe

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

At 05:44 AM 11/20/2003, Indranil Bhattacharya wrote:
>Hi Kurt,
>        What about doing away with ldap_dup() /ldap_destroy () and
>pushing that intelligence into the library implementation ? 

Well, that's certainly a possibility.  (Netscape did it that way.)

I took the ldap_dup() approach for a couple of reasons.  Most
importantly, I wanted to allow some callers sharing a LDAP session
to have caller-specific state (and not have caller equated with thread
necessarily).  That is, a dup'ed handle can have different option
settings than its parent handle.

Note that duplicate session handles have applicability even in
non-threaded environments.  For example, a single-threaded proxy
could use duplicate handles to maintain different proxy
authorization controls for different users.  That is, dup'ing
the parent handle for each new client and setting the proxyAuthz
control for that client in the dup'ed handle for the client.

And when one wants to thread-ize this proxy, note that duplicate
state is not per thread but per duplicated handle.  This means
the proxy is free to use any thread to interact with the session
on the appropriate duplicated handle.

>        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.

Note that one would have to implement a portable thread-specific-data
mechanism to take this approach.


>        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 
>>