[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.
Kurt
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
>useful.
>
>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:
>
> LDAP_OPT_DEREF LDAP_OPT_SIZELIMIT LDAP_OPT_TIMELIMIT
> LDAP_OPT_RESTART LDAP_OPT_CLIENT_CONTROLS
> LDAP_OPT_SERVER_CONTROLS LDAP_OPT_ERROR_NUMBER
> LDAP_OPT_ERROR_STRING LDAP_OPT_MATCHED_DN
>
>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
>them.
>
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support