* 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/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
