Re: defect

[Joe L. <jl...@op...>]

On Friday, June 28, 2002, at 12:00 PM, Michael Str=F6der wrote:

> Joe Little wrote:
>> two snippets from Luke when speaking about 2.1
>
> Note that most people still build against OpenLDAP 2.0.x. I don't want=20=

> to mandate OpenLDAP 2.1.x at the moment because there will surely be=20=

> more complaints about this than about bad performance.

Agreed. I talked with Luke about 2.1's improvements in this area, and=20
he replied that 2.0 already was thread safe. I'll be diving into 2.1,=20
but 2.0 should be sufficient for coding thread safe python-ldap once it=20=

uses libldap_r.

>
> I don't like #ifdef's either. Lesson learned so far: I'm not a C=20
> programmer and the guys adding the #ifdef's won't be available for=20
> maintaining the C code later.
>
>> When I mentioned complaints here about thread safety, his response:
>> I haven't seen those complaints. The OpenLDAP client library is=20
>> guaranteed
>> to be thread safe as long as you (a) link against libldap_r and (b) =
do
>> not permit concurrent access to a single LDAP session (ie. use one =
per
>> thread or a mutex around it).
>
> Ok, not really new information. That was also my understanding from=20
> Kurt's postings quite a while ago.
>
> Caveats:
> 1. libldap_r has not been tested with python-ldap yet.
> 2. libldap_r is not fully implemented in OpenLDAP 2.0.x. AFAIK in 2.0=20=

> it's just a hack to make slurpd work.

What I understood from Luke is that it has been completed in 2.x, with=20=

bugs worked out along the way up to 2.0.25.

> 3. We can't get completely rid of locking. We can do finer grained=20
> locking per LDAPObject instance. AFAIK global functions have still  to=20=

> be protected by module-wide locking.
>
>> So, libldap_r is one requirement...
>
> I'd be glad if someone dives into the gory details.
>
>> but the other seems to be already set by our use of internal thread=20=

>> locking to that single session.
>
> At the moment there's a single module-wide lock serializing all calls=20=

> into libldap since this is required with OpenLDAP 2.0.x. This can be=20=

> easily changed off course.
>

Well, I hope this small discussion shows a way forward.


> Ciao, Michael.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Caffeinated soap. No kidding.
> http://thinkgeek.com/sf
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev