apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: OpenLDAP's libldap and libldap_r
Date Fri, 23 Jan 2009 15:14:52 GMT
On Fri, Jan 23, 2009 at 07:10:36AM -0500, Jeff Trawick wrote:
> On Fri, Jan 23, 2009 at 7:00 AM, Eric Covener <covener@gmail.com> wrote:
> > On Fri, Jan 23, 2009 at 3:46 AM, Graham Leggett <minfrin@sharp.fm> 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_* 

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

View raw message