Why LDAPObject.._ldap_object_lock around library calls?

[Michael Ströder]

Ken Key wrote:
> 
> I need to have two threads, a Producer and Consumer (relative to LDAP),
 > [..]
> translates the results into
> a form my proxy protocol and puts it on the work result Queue.

I probably don't understand what you're after. However I try to give some 
answers.

>>According to related postings on the OpenLDAP lists libldap_r is
>>re-entrant
>>on a per-connection basis. Therefore linking with libldap_r improves the
>>situation since a finer-grained locking is used in LDAPObject class (see
>>method _ldap_lock()).
> 
> However, the lock is still across all methods of an instance of the
> LDAPObject, and thus in force for all operations on the connection,
> across all threads.  That's the problem.

Your threads should use different LDAP connections thus LDAPObject instances.

> I was trying to determine if there were reasons beyond the
> underlying binary OpenLDAP client libraries that the locking was in
> place.

The OpenLDAP libs are the problem. Nothing in python-ldap requires the locks.

>  If not, I was thinking of overriding the _ldap_call() in
> my own class and eliminating it, since the ldap_r is a requirement
> for my proxy's environment.

Don't do this! The OpenLDAP libs are not re-entrant within one connection 
context. See OpenLDAP mailings list archives for details.

Ciao, Michael.