Re: defect

[<mi...@st...>]

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 to mandate OpenLDAP 2.1.x at the moment because there will 
surely be more complaints about this than about bad performance.

I don't like #ifdef's either. Lesson learned so far: I'm not a C 
programmer and the guys adding the #ifdef's won't be available for 
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 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 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 it's just a hack to make slurpd work.
3. We can't get completely rid of locking. We can do finer grained 
locking per LDAPObject instance. AFAIK global functions have still 
  to 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 locking to that single session.

At the moment there's a single module-wide lock serializing all 
calls into libldap since this is required with OpenLDAP 2.0.x. 
This can be easily changed off course.

Ciao, Michael.