[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Operation thread-safe

Hi Kurt,
            The implementation that I have talked about in my earlier
mail ( ldap_dup()/ldap_destroy() ; also the serialization of common data
structures within ld ) is complete. Everything seems to be working
fine.
            Maybe, we can try to make this draft
(http://www.watersprings.org/pub/id/draft-zeilenga-ldap-c-api-concurrency-00.txt)
as a standard. Is this an eligible candidate for a standard ? Let us
know your views on this.


regards,
Indranil
     

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/18/2003 10:24:48 PM >>>
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
--- Begin Message --- 
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 
>>

--- End Message ---