[Date Prev][Date Next] [Chronological] [Thread] [Top]

framework for multithread LDAP library implementation

I've committed changes to build system to support development of
a multithread LDAP library implementation.   The framework is
designed such that a separate library (-lldap_r) will can be built
from the existing codebase.  When compiling for this library
-DLDAP_R_COMPILE is defined.  This flag will be used to conditional
modifiy the code for reentrancy and threading.

I wrote on ietf-ldapext mailing list:
>Applications could define something like -DLDAP_THREAD_SAFE
>(instead of over loading -D_REENTRANT/-D_THREAD_SAFE and their
>varients) before including <ldap.h>.

and will be required to link with -lldap_r and possibly other libraries
(like -llthread... which need to rewritten to hide the threading

>ldap.h would have constructs:
>/* Both -lldap and -lldap_r meet this basic level of safeness */
>/* should be moved behind LDAP_THREAD_SAFE is only -lldap_r is this safe */

defined if platform provides reeentrant functions and consisent errno
The LDAP_API_FEATURE_X_OPENLDAP_REENTRANT is defined if -lldap provides
this functionality. 

defined.   LDAP_API_FEATURE_X_OPENLDAP_THREAD_SAFE is defined iff this library
is available.

The application developer defines LDAP_THEAD_SAFE he *should* link against
-lldap_r.  It is recommended that application developers defining
verify the (dynamically?) linked LDAP implementation support the required
level of thread safeness using ldap_get_option(NULL, LDAP_OPT_API_INFO, &ai).


These would be provided when implemented.   Of course, we still need to
implement LDAP_FEATURE_API_FEATURE_THREAD_SAFE when library mutexes are

Here in the code use:
     #if defined( HAVE_REENTRANT_FUNCTIONS ) \
         || defined( HAVE_FUNC_R )
     #   if defined( HAVE_THREADS )
             /* lock */
     #   endif
     #   if defined( HAVE_THREADS )
             /* unlock */
     #   endif

amongst other things (see lthread.h).  HAVE_THREADS is defined in lthread.h
libldap/*.c should only include <lthread.h> (and friends) iff
LDAP_R_COMPILE is defined.
	#include <lthread.h>

LDAP_R_COMPILE is defined by libldap_r/Makefile.in
specifically for compiling the threadsafe version of
the ldap library (-lldap_r). 

To build -lldap_r, cd to libraries/libldap_r and type 'make'.

Of course, the reentrancy/threading has yet to be implemented.
So all of the above may completely change...  but it should
be enough for folks to toy with threading.

(ie: not me, I need to get back to work on the C-API and LDAPv3)

>On 11/12/98, I wrote:
>>I would to extend the API to support some basic
>>compile time and run time checking of thread
>>safeness.  I also have some comments in regarding
>>Section 23.1, p 60.
>>If defined, the implementation can be used in
>>a threaded environment where all LDAP API 
>>calls are restricted to one thread of execution.
>>This feature SHOULD be implemented.
>>If defined, the implementation can be used
>>in a threaded environment where all LDAP API
>>calls associated with a LDAP session are
>>restricted to one thread of execution.  LDAP
>>global operations and ldap_init()/ldap_open()
>>calls, however, are restricted to one thread.
>>This feature is RECOMMENDED to be implemented.
>>If defined, the implementation can be used in a
>>threaded environment without restriction.  The
>>threading model may be dictated by the implementation.
>>Optionally, the implementation may provide a mechanism
>>for allowing appplications to providing required threading
>>routines.  If such a mechanism is provided, additional
>>API features should be defined.
>>Implementing LDAP_API_FEATURE_THREAD_SAFE is rather straight
>>forward.   Basically, implementations just have to avoid
>>using any non-threadsafe/non-reentrant library calls.
>>Implementing LDAP_API_FEATURE_SESSION_SAFE may require a
>>some more involved effort to implement, but should not
>>requiring use of any thread library support.  The only
>>issue I see is with global operations and ldap_init/open().
>>Such that thread library support is not needed by the
>>implementation, I've proposed that global calls and
>>ldap_init/open() they be restricted to one thread.
>>require the implementation to use a thread library support
>>and be much more involved.  As such, the specification
>>should give the implementers a wide range of options.  I
>>feel that implementer should be allowed to dictate the
>>thread library used if he/she chooses to.  If he/she does,
>>he/she should probably provide a non threaded implementation
>>as well.  But that should be the implementor's choice.
>>However, I do also support efforts to define a common
>>mechanism to allow the application developer to provide
>>the necessary threading routines.  I believe implementers
>>be required to implement it.
>>When does the implementation initialize any thread
>>specific information?  On the first call?  Or based
>>upon initialization request using either a specific
>>API call, ie: ldap_initialize() (yuk).  Or maybe
>>as a side affect of an specific ldap_set_option()
>>operation, ie: ldap_set_option(NULL, LDAP_OPT_THREADING,
>>LDAP_OPT_ON) (yuk^2).
>>I suggest that the threading specification require
>>the successful completion of any LDAP API routine before
>>any multithreading is supported.  (ie: first API call