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

RE: back-ldap, libldap_r

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