[Date Prev][Date Next]
Re: libldap and _r-functions
At 02:39 AM 5/31/2005, Ralf Haferkamp wrote:
>On Wednesday 25 May 2005 17:35, Kurt D. Zeilenga wrote:
>> At 05:47 AM 5/25/2005, Ralf Haferkamp wrote:
>> >are there specific reasons that the _r-functions (gethostbyname_r,
>> >gethostbyaddr_r, ...) are only used for libldap_r and not libldap?
>> Yes, there are a number of reasons.
>> libldap was never designed for use in programs which
>> aren't built/linked for use with a threaded program. Thread
>> programs may have problems even where that program serializes
>> all calls to the library (because of conflicts between the
>> program's and library's use of system (and dependent library)
>> calls. libldap_r was designed for use in threaded programs,
>> such as slurpd(8). While libldap_r does have a number of
>> limitations, it is safe when used properly.
>> The reason we have two libraries is that, on many systems,
>> threaded and non-threaded programs are required to
>> be compiled/linked differently, and that many of the _r
>> functions are only available to programs compiled/linked
>> as threaded programs.
>Ok, thanks for clarifying that.
>> >I have a problem here where nss_ldap (configured to be used for
>> >resolving hostnames) deadlocks in a gethostbyname() call in libldap.
>> >Building libldap so that it uses gethostbyname_r() fixed that
>> > problem for me.
>> Seems like nss_ldap should have been compiled/linked with
>But wouldn't I get symbol conflicts then with applications that link
>against "normal" libldap on nss_ldap-enabled systems?
Simply put, the NSS (and PAM) architecture is problematic in
that all kinds of code which conflicts with the program can
be linked in at run time. The program has little protection
from the module and the module has little protection from the
program. I don't view this as a OpenLDAP-specific problem,
as there simply is little we can do to prevent program/module
conflicts at the library level. (Not to say that we couldn't
use separate symbols in libldap and libldap_r, but more to
say that use of separate symbols won't do all that much to
prevent program/module conflicts that are inherit in the
NSS (and PAM) architecture).