Hi Rich / Mark, I have been able to sort out the issue. The problem was that the get_errno & set_errno were not thread-safe. It was due to this that the bind thread was not getting the correct error no. & was getting stuck into an infinite loop.
I corrected the function & am now seeing that the simple_bind thread is not hanging. Thanks for all your help & inputs. Thanks, Denish On Tue, Sep 1, 2009 at 10:43 PM, Rich Megginson <[email protected]>wrote: > denish patel wrote: > >> Thanks Rich, >> Let me clarify here. >> >> The Application I am working on is a multi-threaded one >> & in that a single LDAP Handle is used by multiple thread s. >> >> By thread safety, I mean that when this single LDAP Handle is used by >> multiple threads to fire queries/modify to the Directory Server, >> for which simple ldap functions such as ldap_search_ext / ldap_modify >> that reside in the Mozilla LDAP, then we wouldn't want to mix up the >> error/mutex/condition information between these threads. >> >> It is specifically for this reason that we set the thread callback >> functions. >> >> Do correct me if I am wrong. >> >> Some questions here: >> 1) Don't I need to set the thread callback functions given my requirement? >> > > No, you just need to use locking that is compatible with what mozldap is > using. The best way to do that is to get the functions used by mozldap. If > not using NSPR/NSS (not using IPv6 or TLS or SSL), the default thread > libraries provided by the underlying operating system are used. For more > details, see ldap/libraries/libldap/open.c. If using prldap, prldap > replaces these with their NSPR counterparts - see > prldap_install_thread_functions() in > ldap/libraries/libprldap/ldappr-threads.c > > So I guess the best way to do it is to first call into the ldap library to > see what function it's using: > LDAP *ld = ldap_init(...); > /* setup connection for TLS */ > > /* I need to lock the ld */ > struct ldap_thread_fns ld_thr_fns; > ldap_get_option(ld, LDAP_OPT_THREAD_FN_PTRS, &ld_thr_fns); > > if (mymutex == NULL) { > mymutex = ld_thr_fns.ltf_mutex_alloc(); > } > ld_thr_fns.ltf_mutex_lock(mymutex); > > /* do something with ld */ > /* unlock */ > ld_thr_fns.ltf_mutex_unlock(mymutex); > > You could probably just use pthreads or Windows thread primitives, or just > use NSPR thread/mutex functions if you know your application will always > need to support TLS/SSL. > > Finally, if mozldap has been compiled with thread support, it will use > Thread Local Storage to get/set the errno for a particular operation. For > more information, see set_ld_error() and get_ld_error() in open.c - there > are different implementations depending on the platform/threading model. > > 2) If an ssl connection is used & I fire a query then the will LDAP Handle >> used to fire the query >> be thread-safe provided I am not setting the thread callback functions. >> > > The LDAP handle (the LDAP *ld) will not be protected - that is, if one > thread issues a query and another thread issues another operation using the > same LDAP handle, the results may be wrong. So you do need to protect > access to the LDAP handle with a mutex. However, as I have explained above, > this does not mean you need to set the thread callback functions. > > 3) What would be the case if I am using an Open Connection. >> > > What's an Open Connection? > > > >> Thanks, >> Denish >> >> >> >> On Tue, Sep 1, 2009 at 8:26 PM, Rich Megginson <[email protected] >> >wrote: >> >> denish patel wrote: >>> >>> Thanks for your reply Mark, >>>> >>>> I am not sure about whether the prldap library uses >>>> NSPR to provide thread safety or not. >>>> >>>> prldap uses NSPR to provide thread/mutex/condition variable >>> functionality. >>> prldap uses LDAP_OPT_THREAD_FN_PTRS to replace the default system thread >>> functions with NSPR. I'm not sure what you mean by "provide thread >>> safety". >>> >>> >>> However, the LDAP C-SDK is not thread safe & for that >>>> purpose we are using the thread callback functions. >>>> >>>> Only in a few cases is LDAP C SDK not thread safe. What cases are you >>> talking about? >>> >>> >>> Thanks, >>>> Denish >>>> >>>> On Tue, Sep 1, 2009 at 7:12 PM, Mark Smith <[email protected]> >>>> wrote: >>>> >>>> denish patel wrote: >>>> >>>>> Hi once again, >>>>> >>>>>> Some more of my observations: >>>>>> >>>>>> When LDAP_OPT_THREAD_FN_PTRS parameter is set the program goes into a >>>>>> loop. >>>>>> Debugging more it was found that the get_errno function is invoked by >>>>>> nsldapi_send_ber_message (Line No. 402 - request.c). >>>>>> >>>>>> 402. int terrno = LDAP_GET_ERRNO( ld ); >>>>>> 403. if ( NSLDAPI_ERRNO_IO_INPROGRESS( terrno )) { >>>>>> 404. if ( async ) { >>>>>> 405. rc = -2; >>>>>> 406. break; >>>>>> 407. } >>>>>> 408. } else { >>>>>> 409. nsldapi_connection_lost_nolock( ld, sb ); >>>>>> 410. rc = -1; /* fatal error */ >>>>>> 411. break; >>>>>> 412. } >>>>>> >>>>>> It is from #402 that the get_errno function is invoked. This function >>>>>> returns 11 as mentioned in an earlier mail. >>>>>> >>>>>> The difference between the hanging & the non-hanging program lies >>>>>> here. >>>>>> When we do not set LDAP_OPT_THREAD_FN_PTRS, the value I see for terrno >>>>>> is >>>>>> 0, >>>>>> whereas it's value is 11 when the parameter has been set. >>>>>> ... >>>>>> >>>>>> I am not 100% sure what is causing the problem you are experiencing >>>>>> (it >>>>>> >>>>> seems like your errno callback function is not returning the operating >>>>> system's errno value). >>>>> >>>>> I do not think this is well documented, but it is not a good idea to >>>>> mix >>>>> together use of your own thread callback functions and the prldap >>>>> library >>>>> (which is always used when you call the Mozilla LDAP C SDK SSL >>>>> functions). >>>>> Do you really need to install your own thread callback functions? The >>>>> prldap library uses NSPR to provide thread safety, and NSPR does a very >>>>> nice >>>>> job of hiding OS differences, etc. >>>>> >>>>> -- >>>>> Mark Smith >>>>> Pearl Crescent >>>>> http://pearlcrescent.com/ >>>>> >>>>> >>>>> > _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
