[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:
>[snip]
>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
implementation).
>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 */
>#define LDAP_API_FEATURE_THREAD_SAFE
With -lldap (ie: -ULDAP_THREAD_SAFE), LDAP_API_FEATURE_THREAD_SAFE is only
defined if platform provides reeentrant functions and consisent errno
handling.
The LDAP_API_FEATURE_X_OPENLDAP_REENTRANT is defined if -lldap provides
this functionality.
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
is available.
The application developer defines LDAP_THEAD_SAFE he *should* link against
-lldap_r. It is recommended that application developers defining
LDAP_THREAD_SAFE
verify the (dynamically?) linked LDAP implementation support the required
level of thread safeness using ldap_get_option(NULL, LDAP_OPT_API_INFO, &ai).
>#ifdef LDAP_THREAD_SAFE
>#define LDAP_API_FEATURE_SESSION_SAFE
>#define LDAP_API_FEATURE_OPERATION_THREAD_SAFE
>#endif
These would be provided when implemented. Of course, we still need to
implement LDAP_FEATURE_API_FEATURE_THREAD_SAFE when library mutexes are
required (-ULDAP_API_FEATURE_X_OPENLDAP_REENTRANT).
Here in the code use:
#if defined( HAVE_REENTRANT_FUNCTIONS ) \
|| defined( HAVE_FUNC_R )
func_r(...);
#else
# if defined( HAVE_THREADS )
/* lock */
# endif
func(...);
# if defined( HAVE_THREADS )
/* unlock */
# endif
#endif
HAVE_REENTRANT_FUNCTIONS is derived from:
_POSIX_REENTRANT_FUNCTIONS
_POSIX_THREAD_SAFE_FUNCTIONS
_POSIX_THREADSAFE_FUNCTIONS
amongst other things (see lthread.h). HAVE_THREADS is defined in lthread.h
iff -UNO_THREADS
libldap/*.c should only include <lthread.h> (and friends) iff
LDAP_R_COMPILE is defined.
#ifdef LDAP_R_COMPILE
#include <lthread.h>
#endif
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.
>>
>>
>>LDAP_API_FEATURE_THREAD_SAFE
>>
>>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.
>>
>>LDAP_API_FEATURE_SESSION_THREAD_SAFE
>>
>>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.
>>
>>LDAP_API_FEATURE_OPERATION_THREAD_SAFE
>>
>>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,
>>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
>>initialization).
>>
>>Kurt