[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: Operation thread-safe

To: "Bhattacharya Indranil" <bindranil@novell.com>
Subject: Re: Operation thread-safe
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Date: Sat, 13 Dec 2003 06:31:30 -0800
Cc: "Anil Kumar Kommuri" <KKanil@novell.com>, "Ravi C R" <RRavi@novell.com>, <openldap-devel@OpenLDAP.org>
In-reply-to: <sfd67527.041@prv-mail25.provo.novell.com>
References: <sfd67527.041@prv-mail25.provo.novell.com>
At 12:21 AM 12/10/2003, Bhattacharya Indranil wrote:
>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.

Great.  I look forward to reviewing your patch (submit as an ITS).

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

Formal standardization of the LDAP C API, including extensions
such as this, is dead in the IETF.  Eventually, maybe this will
all make it out as Informational RFC (as was RFC 1823).  But
that would require much more energy than appears presently
available to do so.

Kurt



>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 
>Return-path: <Kurt@openldap.org>
>Received: from NAXOS.novell.com
>        (naxos.provo.novell.com [130.57.1.13])
>        by prv-mail20.provo.novell.com; Sun, 23 Nov 2003 09:58:50 -0700
>Received: from pretender.boolean.net (unverified [198.144.206.49]) by NAXOS.novell.com
> (Vircom SMTPRS 2.1.260) with ESMTP id <B0003116326@NAXOS.novell.com> for <bindranil@novell.com>;
> Sun, 23 Nov 2003 10:00:33 -0700
>Received: from gypsy.OpenLDAP.org (kurt@localhost [127.0.0.1])
>        by pretender.boolean.net (8.12.9/8.12.9) with ESMTP id hANGwmlg081019;
>        Sun, 23 Nov 2003 16:58:48 GMT
>        (envelope-from Kurt@OpenLDAP.org)
>Message-Id: <6.0.0.22.0.20031123083115.03adc268@127.0.0.1>
>X-Sender: kurt@127.0.0.1
>X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
>Date: Sun, 23 Nov 2003 08:58:05 -0800
>To: Indranil Bhattacharya <bindranil@novell.com>
>From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
>Subject: Re: Operation thread-safe
>Cc: OpenLdap-Devel <openldap-devel@OpenLDAP.org>
>In-Reply-To: <1069335880.2113.12.camel@BIndranil>
>References: <1069077940.1825.63.camel@BIndranil>
> <6.0.0.22.0.20031118084838.034fb2f8@127.0.0.1>
> <1069335880.2113.12.camel@BIndranil>
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>
>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 
>>>
References:
- Re: Operation thread-safe
  - From: "Bhattacharya Indranil" <bindranil@novell.com>
Prev by Date: Re: saslAuthz{To|From}
Next by Date: Re: HEADS UP: API error code changes
Index(es):
- Chronological
- Thread