I'm having a problem with the nsIEventQueueService's ResolveEventQueue method that really has me baffled. I believe it's the cause of a related problem that I've recently posted in the embedding newsgroup, but I haven't received an answer there and am hoping someone here might know. In any case, it seems to be more appropriate to this newsgroup.
The problem is that 3 out of 4 times I run my app, everything works great and this method returns the correct event queue. However, on certain rare (and seemingly random occassions), this method returns NS_ERROR_FAILURE and does so consistently. I've traced the error back to this block of code in GetThreadEventQueue, which is called by ResolveEventQueue:
else if (keyThread == NS_UI_THREAD) { nsCOMPtr<nsIThread> mainIThread;
// Get the primordial thread nsresult rv = nsIThread::GetMainThread(getter_AddRefs(mainIThread)); if (NS_FAILED(rv)) return rv;
rv = mainIThread->GetPRThread(&keyThread); if (NS_FAILED(rv)) return rv; //<---Returns NS_ERROR_FAILURE }
When I looked at the code for GetPRThread, the only reason it would return NS_ERROR_FAILURE is if the thread's mDead member is true, meaning that my primordial thread is dead. As far as I can tell, mDead only gets set by nsThread::Exit. I have absolutely no idea why my primordial thread would be considered dead, as it is still happily running the Windows message pump, and since ResolveEventQueue works just fine most times I run my app.
This problem came up while trying to create an nsISupports proxy on the UI thread. Since of course GetPRThread returns NS_ERROR_FAILURE, neither proxies nor PLEvents work.
In case it helps, the following is a detailed description of what I'm attempting to do. I'm embedding Mozilla into a Java app. Here are the basic steps:
1. Java loads my DLL that has some JNI methods as well as my Mozilla embedding code 2. Java calls an initialization method inside my DLL to initialize Mozilla embedding 3. My initialization method creates a native Win32 thread that is to act as the primordial thread and Windows message pump, and then calls NS_InitEmbedding, etc. 4. Sometime later, from another Java thread, I call into my DLL to create an instance of nsWebBrowser, via nsIProxyObjectManager::GetProxy so that I can safely use it on a non-primordial thread. 5. Use the proxy to navigate, etc.
I originally thought my problem was that nsWebBrowser does not have a thread-safe nsISupports implementation, but it turns out in fact that it works great as long as ResolveEventQueue (which is called by the proxy code) works, and when it doesn't work, I have verified that ResolveEventQueue is failing. When I tried to use PLEvents to accomplish the same thing (for fear that the non-thread-safe nsISupports was causing the problem), I discovered the root of the problem.
It appears that for some reason my native thread isn't being attached properly to a PRThread, or else something is calling Exit on it too soon. If anyone could give me some hints as to possible causes I would greatly appreciate it. With all the event queues, proxies, nsIThreads, PRThreads, etc., I just don't know what the possible cause could be. Thanks in advance. -- Brad Fish [EMAIL PROTECTED] TALL Group Programmer
could it be the case that the second java thread is trying to access the proxy instance of nsWebBrowser before mozilla's "primordial" thread has been completely initialized? i.e., are you sure mozilla's has even completely setup the event queue and main thread data structures?
darin
