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

RE: back-ldap, libldap_r

Aside from there being way to much "state" and "defaults" in
associated with the current handle, I do like the idea of
duplicate handles.  Each handle is basically synchronization
device to manage shared access of a common resource.  Much
like duplicated file descriptors.


At 04:19 PM 12/21/2002, Howard Chu wrote:
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>> The other alterative is to do something like:
>> http://www.watersprings.org/pub/id/draft-zeilenga-ldap-c-api-c
>> oncurrency-00.txt
>> Note that this is just food for thought...
>In the previous email I focused on the Error Reporting Extension because that
>is a prerequisite of the proposed Concurrency Extensions. Now I have a few
>comments about the Concurrency Extensions themselves...
>Regarding Session Thread Safe and Operation Thread Safe implementation
>levels - it strikes me that once you've guaranteed atomicity of the
>operations on a session handle, then the distinction between these two is not
>The Operation Thread Safe implementation is based on a notion of duplicated
>session handles, to allow different handles to maintain different state. I
>believe this is the wrong way to deal with these state items. In particular,
>these session options are listed as private to a handle instance:
>I suggest we should only treat these as properties of a particular operation.
>Rather than having a single set of these properties in an individual session
>handle, they should be accessed by a (handle,msgid) pair. With this in mind,
>there is no need for duplicate session handles. The SIZELIMIT and TIMELIMIT
>options are already part of the search API, DEREF should be added there. The
>Controls are also already part of the per-operation API, and the error
>number, error string, and matchedDN are already handled by ldap_parse_result.
>It makes no sense to associate these values with the session since they are
>specific to a given operation. They still serve a purpose as session-wide
>defaults, but otherwise there are other more appropriate means for using
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support