[Pkg-openldap-devel] Bug#340601: libldap issues

[Howard Chu]

>>  * libldap has no supported thread-safe API.  Threaded programs that link
>>    against libldap are required to handle locking themselves.
>
> Wow, ok, I'm very not happy with this answer.

Russ left out a pertinent comment. I said:
>>> Until somebody decides to invest some energy into writing a new C API spec,
>>> (simply dusting off the expired C API draft won't cut it) there is not and
>>> will never be any official support for threading/re-entrancy in the LDAP API.

> I think that *all* libraries should have thread-safe APIs;

We all agree on that. Thus this page
http://scratchpad.wikia.com/wiki/LDAP_C_API

but it's not going to happen until more people get involved.

 > and aside from this minor blemish, libldap_r
> appears to already be a perfectly good thread-safe, reentrant library,
> supported by upstream or not.

Ideally libldap would be re-entrant and free-threaded. But there are so many 
other problems with the API already, we're not interested in putting any more 
bandaids on it. We need a ground-up effort at defining a new API. We may not 
have to throw out 100% of what we have today, but there's no point in 
continuing to patch it. It's junk, and needs to be rewritten.

> We have the following callers using libldap in Debian which also have need
> of thread-safety and currently take no additional steps to ensure libldap is
> thread-safe:

> - libnss-ldap

Not true, nss_ldap already locks itself to prevent re-entrance. As such, it 
*must* only be linked with libldap, not libldap_r. (Remember, nss_ldap was 
written to work with other vendors' libraries too, and none of them are 
re-entrant, so it has to do the locking itself.)
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/