A couple of things to note: See bugs 98755 and more generally 101976 for known threadsafety problems in xpcom.
Also, the mime assertion that you are seeing should be fixed in the trunk. When the nsFileIO class no longer eagerly searches for mime types. Regards, Doug Turner Paul Rouleau wrote: > I added the following two lines of code after my call to NS_InitEmbedding( ).... > > nsCOMPtr<nsIMIMEService> mMimeService; > mMimeService = do_GetService(NS_MIMESERVICE_CONTRACTID); > > > .... and that seemed to do the trick.... No more asserts. > > Obviously, this is a hack, but I'll leave it in and check newer releases and see if > it will still be necessary. > > Thanks John for your help. > > - Paul > > > > Paul Rouleau wrote: > > >>Ok, I'll try it.... >> >>.....but, I'm not exactly sure what component I should create (nsFileTransport, >>nsFileIO, nsTransportService or nsCOMPtr<nsIMIMEService> (see callstack below). >> >>Or, is this something that initiated from outside this thread. If that is the >>case, should I be trying to create something else? >> >>Nonetheless, I'll try each class in the callstack and see what happens. >> >>I'm sorry if I sound like a newbee (....although, I am...). >> >>Thanks for your help, >> - Paul >> >>John Bandhauer wrote: >> >> >>>I bet the difference is that (for whatever reason) in your >>>embedding the *first* time an instance of that particular >>>component is created happens on a thread other than the main >>>thread, while in other embeddings the first instance is created >>>on the main thread at some time before this. >>> >>>The component loader is only called to get the factory the first >>>time the factory is needed. On subsequent calls to create an >>>instance (on whatever thread) the component manager will just use >>>its cached factory and will not call the component loader at all. >>> >>>The lack of full free threading access to the component loader is >>>very ugly and ought to be fixed. >>> >>>I hate even saying this, but... As a stupid workaround you might >>>try creating and releasing an instance of that particular >>>component on your main thread right after xpcom init and before >>>any other threads start using xpcom. >>> >>>John. >>> >>>Paul Rouleau wrote: >>> >>>>hmmm.. That would explain why I'm getting the assert, but I don't >>>>understand how this is invoked, (and why it doesn't happen to mfcembed). >>>> >>>>Below is my callstack..... >>>> >>>> NTDLL! 77f7629c() >>>> nsDebug::Assertion() line 290 + 13 bytes >>>> NS_CheckThreadSafe() line 528 + 34 bytes >>>> nsNativeComponentLoader::AddRef() line 90 + 54 bytes >>>> nsComponentManagerImpl::GetLoaderForType() line 2536 >>>> nsFactoryEntry::GetFactory() line 328 + 39 bytes >>>> nsComponentManagerImpl::FindFactory() line 1437 >>>> nsComponentManagerImpl::CreateInstanceByContractID() line 1666 + 16 >>>> bytes >>>> nsComponentManagerImpl::GetServiceByContractID() line 2059 + 50 bytes >>>> nsGetServiceByContractID::operator()() line 246 + 38 bytes >>>> nsCOMPtr<nsIMIMEService>::assign_from_helper() line 972 + 18 bytes >>>> nsCOMPtr<nsIMIMEService>::operator=() line 604 >>>> nsFileTransportService::GetCachedMimeService() line 119 + 31 bytes >>>> nsFileIO::Open() line 218 + 8 bytes >>>> nsFileTransport::Process() line 670 + 58 bytes >>>> nsFileTransport::Run() line 638 >>>> nsThreadPoolRunnable::Run() line 904 + 12 bytes >>>> nsThread::Main() line 120 + 26 bytes >>>> _PR_NativeRunThread() line 413 + 13 bytes >>>> MSVCRTD! 0025bf53() >>>> KERNEL32! 77f04ee8() >>>> >>>>It looks like this is getting triggered by a call to nsFileIO with a >>>>file name that exists in the cache. >>>> >>>> >>>>I do not explicitly call this thread to do anything. I believe it is >>>>triggered within nsIWebNavigation::LoadURL. >>>> >>>>I'm guessing that either I'm not compiling my program correctly (wrong >>>>compile switch or missing #define), or my mozilla configuration is not >>>>consistant with that of mfcembed. >>>> >>>>Any ideas? >>>> >>>>Thanks, >>>> Paul >>>> >>>> >>>> >>>>David Bradley wrote: >>>> >>>> Paul Rouleau wrote: >>>> >>>> > What does this assertion mean? >>>> >>>> It means that you are invoking a method on the component loader from a >>>> thread different than the one that created it. Which exposes it to >>>> potential threading problems. >>>> >>> >
