Why LDAPObject.._ldap_object_lock around library calls?

[Michael Ströder]

Ken Key wrote:
> Ah, I found the answer to my question.  Since we store the thread
> state in the LDAPObject instance, the object cannot be shared between
> my two threads.

It can be shared. That's what the locks are for. But not in a completely 
async manner like you're trying. Maybe your problem is that you are using 
result2() in a blocking manner. You can let it somewhat poll the results. 
But this is CPU intensive.

(History: I had a non-blocking version of result() in former versions of 
python-ldap to avoid locking over long time spans. But some people 
experienced serious problems with it.)

> I tossed together a prototype of the two-thread model I was thinking of.
> With the LDAPObject._ldap_lock in place, I got the deadlock I was
> afraid of.  When I removed the _ldap_lock.acquire/release in
> _ldap_call() I got the "saving thread twice?" fatal error from the
> LDAP_BEGIN_ALLOW_THREADS() when the second thread makes the second
> function call.

Don't mess around with the locks! They are needed because of the OpenLDAP libs.

Ciao, Michael.