On Fri, Jan 23, 2009 at 07:10:36AM -0500, Jeff Trawick wrote: > On Fri, Jan 23, 2009 at 7:00 AM, Eric Covener <[email protected]> wrote: > > On Fri, Jan 23, 2009 at 3:46 AM, Graham Leggett <[email protected]> wrote: > > > This is the first time I have heard of ldap_r. Is there a reason why we > > > can't just try bind to ldap_r first, and if that fails fall back to ldap? > > > > I think that's the way to go. > > Yeah, sounds right. > > FWIW, /usr/sbin/httpd.worker on RHEL 5 U2 loads just plain libldap (and > libldap_r is a distinct, and larger, library). A naive observer (okay, me) > would have expected that to be an explosive combination that would have been > fixed long ago.
>From reading the OpenLDAP source code the libldap_r build appears to compile in a bunch of mutex locking calls around many/most of the ldap_* interfaces. It's not obvious to me whether: a) this is because those calls are in fact manipulating process-global state in some thread-unsafe way (not obvious how, if so), or b) this is enabling an additional API guarantee, that concurrent use of a single LDAP * object from multiple threads is safe. I would assume any user of this apr-util API, hahaha sorry, let me start again.... I would assume that httpd does not rely on the additional API guarantee in (b). Since libldap and libldap_r seem to implement the same set of symbols (and without symbol versioning) this kind of issue is a minefield for downstream distributors, if apr-util/httpd link against libldap_r and some perl LDAP foo links against libldap, everything goes boom. Regards, Joe
