[Date Prev][Date Next]
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 */
With -lldap (ie: -ULDAP_THREAD_SAFE), LDAP_API_FEATURE_THREAD_SAFE is only
defined if platform provides reeentrant functions and consisent errno
The LDAP_API_FEATURE_X_OPENLDAP_REENTRANT is defined if -lldap provides
With -lldap_r (ie: -DLDAP_THREAD_SAFE), LDAP_API_FEATURE_THREAD_SAFE is always
defined. LDAP_API_FEATURE_X_OPENLDAP_THREAD_SAFE is defined iff this library
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 */
# if defined( HAVE_THREADS )
/* unlock */
HAVE_REENTRANT_FUNCTIONS is derived from:
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.
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.
>>Implementing LDAP_API_FEATURE_OPERATION_THREAD_SAFE would
>>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
>>of LDAP_API_FEATURE_OPERATION_THREAD_SAFE should NOT
>>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,
>>I suggest that the threading specification require
>>the successful completion of any LDAP API routine before
>>any multithreading is supported. (ie: first API call