RamaKrishna Narla wrote:
Hi,
LDAP (Mozilla LDAP C SDK) asynchronous calls like ldap_simple_bind,
ldap_search (not ldap_search_ext), ldap_result ...etc, return -1 on
error and set the actual error details into LDAP connection handle.
If two processing threads using the same LDAP connection handle fails
in these kind of operations, then both of them will set the error
details into the same LDAP connection handle. So the error number
obtained with ldap_get_lderrno() function may not be the one set by
this processing thread.
So, these operations are seem to be not multi-thread safe, if both the
threads use the same connection handle.
That is not correct. Typically, libldap uses thread local storage to
ensure that the setting and retrieving result codes is MT safe. A set
of thread callback functions are installed by default, or you can
install your own thread functions, or if you use NSPR the libprldap
library takes care of these issues for you.
In LDAP v3, we have serveral new functions like ldap_search_ext,
ldap_modify_ext ...etc. But, it seems like we do not have similar
functions for ldap_simple_bind and ldap_result.
Despite the function's name, you can use ldap_sasl_bind() to send a
simple bind request (pass LDAP_SASL_SIMPLE for the mechanism name). But
for ldap_result(), there is really no other alternative.
I would like to know in what all cases these two methods return -1 (and
set the error number into connection handle)? Does anybody have any
idea on this? Mozilla LDAP SDK documentation simply gives a pointer to
the list of all feasible error codes, which seem to be incorrect.
You would have to read the source code to determine all of these cases
where -1 might be returned (there are many possible reasons). If you
have a thread safety issue with the LDAP * handles, you will need to fix
that regardless so I would focus on that area.
-Mark
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap
