Hey Darren, First I must tell you that this is totally not supported. Most of the interfaces that you are wind up using to do this are not frozen. Every mozilla change to these unfrozen API will brake your driver. The only solution that you may be able to use is releasing a build of your SDBC driver for every point release (not fun).
As we approach mozilla 1.0, more of the API will be frozen, but I know for fact, that event queue management, and proxy management will not be included (intentionally). I would be surprised if the nsIAb* interfaces were frozen, but I defer to a mailnews owner. On to the bug... Could you send me stack traces of the two threads that are involved in the dead lock? Maybe even file a bug with all the info. Thanks, Doug Turner Darren Kenny wrote: >Hi, > >I'm working on OpenOffice writing an SDBC driver to access the Mozilla addressbooks >via the Mozilla nsIAb* interfaces, ie. I'm using Mozilla's components withing >OpenOffice. > >I'm performing initialization of Mozilla pretty much the same way NS_InitEmbedding() >works (except for the initialization of the chrome registry as we don't use XUL in >anyway in our code and no auto-registration, we want to control this), ie: > >- Init XPCOM >- Create an EventQ >- Create a StartupNotifier nsIObserver and call Observe >- Create an nsIStringBundleService > >The problem I'm having is in relation to the use of the nsIAbLDAPDirectoryQuery >interfaces in Mozilla 0.9.5. Everything used to work perfectly until the >introduction of a ProxyObject to handle an nsDNSListener object in nsLDAPConnection. >(Believe me I've debugged this enough to know that this is where things are >going wrong)... > >What appears to be happening is that a ProxyObject is created (using the >PROXT_SYNC and PROXY_ALWAYS flags) and this is passed successfully into the >nsDnsService and nsDnsLookup interfaces... Later when a DNS lookup has >been successfully done, an attempt is made in the nsDnsLookup::FireStop() >method to call the OnFound method of the nsDNSListener via the ProxyObject. >Debugging into the ProxyObject, there are two seperate threads in use >so it doesn't call the nsDNSListener::OnFound() method directly, it >successfully calls PostAndWait, which in turn calls Post() successfully >and then waits... (it also has to create an eventQ for the thread it's >running in because there isn't one already present). > >It's seems that (since there's no timeout on this) the wait then continues >indefinately, never returning. If I examine all threads I notice two calls >to PR_WaitCondVar (or something like that), one in the ProxyObject code >and another in what seems to be the eventQ that's created during >initialization. It seems like deadlock, but I'm not 100% sure of this, all >I know for definate is that the nsDNSListener::OnFound() method is never >actually called, and so it never returns. > >There are a couple of points that might be of interest: > >1) We're not using a full set of components (though using the full set still > exhibits the same behaviour) > >2) We're not calling NS_InitEmbedding() but even if we do, things still > work the same. > >3) This problem has not been reproduced in Mozilla yet, I can only see > it in the enviroment I'm using (ie. OpenOffice + Mozilla "embedded") > but that doesn't mean it's not there... > >4) There may still be some outstanding initialization that occurs in > Mozilla itself, which I'm not doing, but I've no idea what... > >5) I've reproduced this problem exactly the same way on Win2K and Linux. > >If anyone could please help or at least shed some light on what might be >causing the failure to call the OnFound method, it'd be much appreciated, > >Many Thanks, > >Darren. >
