[Date Prev][Date Next]
- To: Howard Chu <firstname.lastname@example.org>
- Subject: Re: libldap_r
- From: Philip Guenther <email@example.com>
- Date: Thu, 24 Sep 2009 18:54:51 -0700
- Cc: OpenLDAP Devel <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1253843706; bh=1L1/zY6KIZX3aUpnFPCgdB35HHHAcuMUtOELM TN+A0M=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID: References:MIME-Version:Content-Type; b=VlzKApjrH1nS1gBDz5KbdU0GTj 19iabmokfPbH74cbWPNUy23UAdi0D9o/zbKtNsHoqJNR1KePC904pbgteSfV/jG8W9P f2ZyKQ8G6IF0F98iElGwmDJu/ibPmaWSZRMgID9BoERfmzh8vr1uSFCTWiu+WA/41kF i7NS6iEJbE8=
- In-reply-to: <4ABC05C1.email@example.com>
- References: <4ABC05C1.firstname.lastname@example.org>
- User-agent: Alpine 2.00 (BSO 1167 2008-08-23)
On Thu, 24 Sep 2009, Howard Chu wrote:
> It seems the dichotomy between libldap and libldap_r is a relic from the
> bad old days of dcethreads / cmathreads when linking a threaded library
> into an otherwise non-threaded program would cause all sorts of strange
> and wonderful failures.
Hmm, my impression from reading the source was that it was more about use
models, where libldap is appropriate when any given LDAP handle would not
be accessed concurrently by multiple threads and libldap_r is appropriate
when a given LDAP handle may be serviced/used concurrently by multiple
Indeed, my impression from reading the ldap_r bits was that processing of
replies wasn't ideal when threads were asking for specific replies, as
asking for a given reply blocked *all* other ldap_result() calls on that
handle until that specific reply was received.
(To hopefully make clear:
return from ldap_result
return from ldap_result
For an application design where that would be a problem, it's better off
with independent handles or its own demultiplexor...at which point all
those locks inside the LDAP handle are just overhead. At Sendmail,
several of our commercial programs use a library to manage reconnections,
resubmitting queries after failover between servers, etc. They all just
link against libldap** and not libldap_r, despite having multiple threads
concurrently in the LDAP code, because those extra locks would be wasted
given the design.
** compiled with whatever it takes to get a thread-safe errno, etc
> libldap_r is still missing some thread-specific features though - we should
> wrap all library initialization in a pthread_once() call, and we should be
> using thread-specific data for the LDAP* errno value.
Without knowing what usage models this is supposed to address or provide,
I don't see the benefit.