Why LDAPObject.._ldap_object_lock around library calls?
key at KSquared.NET
Wed May 5 19:31:17 CEST 2004
> 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
> 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!
More information about the python-ldap