Why LDAPObject.._ldap_object_lock around library calls?

[Ken Key]

> Ken Key wrote:
>>
>>   I'm having a little trouble with the _ldap_object_lock in the
>> LDAPObject around ldap library function calls.
>
> Which trouble do you have?

I have to admit that at this point the problem is theoretical.  I have
yet to implement the code.  This is based on my visual inspection of
how things work beneath me.

I need to have two threads, a Producer and Consumer (relative to LDAP),
accessing LDAP library calls.  The Producer thread idles on a work request
Queue.  It formulates async LDAP requests which resulting in async
ldap_add/_modify/_delete/_search operation.  The Consumer thread
idles on the ldap_result(), takes the msgid to find the matching
outstanding async operation, translates the results into
a form my proxy protocol and puts it on the work result Queue.  This
means that the Consumer thread's idle state is sitting in the
ldap_result() call (waiting on it's select()).  As a resulting,
it will be holding the _ldap_object_lock() for the connection.
When my Producer thread gets it's work request, it cannot make it's async
calls as it will be blocked on the self._ldap_object_lock.acquire()

>>  Is the link
>> to protect against threads making function calls when the _ldap
>> module is linked against the non-reentrant version of the libldap?
>> That is, wouldn't it be safe to get rid of the _ldap_object_lock
>> references in LDAPObject._ldap_call() if the module is linked
>> against libldap_r?  Or is there some other, non-threadsafe reason
>> that I'm missing?
>
> 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.

> Note that proper support for libldap_r also depends on the version of the
> OpenLDAP libs used.

Understood.  I was trying to determine if there were reasons beyond the
underlying binary OpenLDAP client libraries that the locking was in
place.  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.

At this point the question is mostly academic for me, as I am changing my
model to a pool of worker-threads, each with their own connection.
I kinda hate doing that as it can't be as effecient as sharing
the connection and processing async.  I may switch back if I can
figure out how to do so safely.

Thanks for the info!
K^2