Re: List of cases in which ldap_result returns -1?

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