Re: Thread safety question

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

First off, let me say that -lldap_r is a bit experimental.
It works fine for slurpd(8), but your mileage may vary.

Basically, where -lldap requires all LDAP API calls (and
some misc system API calls) to be serialized, -lldap allows
for calls related to a particular LDAP handle to be made
in a separate thread of execution.

At 05:59 AM 2002-01-03, Michael Ströder wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> At 07:17 AM 2002-01-02, Don Zick wrote:
>> >Is it safe for one application thread to call ldap_search() and another
>> >to call ldap_result()?
>> 
>> When using -lldap_r, an application can use each LDAP session
>> handle in one thread at a time.  Normally, the application
>> ensures this by restricting operations upon a handle to one
>> thread, however the application is free to use other means
>> to serialize calls upon a handle.
>> 
>> Also note that calls which don't take a session handle also
>> need to be serialized...
>
>Interesting topic.
>
>I'm currently maintaining python-ldap which is mainly a C wrapper
>module around the OpenLDAP 2 libs. The LDAP session handle once
>gathered is solely used within a LDAPObject instance.
>
>At the moment I'm serializing *all* calls into libldap with a single
>global lock (global functions like ldap_initialize() and LDAP
>operations implemented as methods of Python class LDAPObject, e.g.
>ldap_search()) which is quite unsatisfying in some situations.
>
>Kurt, if I understood your message above correctly with -lldap_r it
>is only necessary to serialize the use of each LDAP session handle
>with a separate lock.
>
>How about calls into global functions ldap_initialize(),
>ldap_set_option() etc. Can I use separate locks for all of these
>functions or do they interfere with each other?

All calls which are not associated with a session handle,
including ldap_init(), must be serialized.  All calls
which are associated with a particular session handle
must be serialized.  But calls associated with different
session handles can be made concurrently. 

That is, for N session handles, you can have N+1 threads
of execution.  One for each session, one for everything
else.