Rajiv Dayal wrote: > Hi, > > I have a separate non UI thread with a Monitored Thread eventQueue for > it. On this thread i want to create an XPCOM object. Using > do_CreateInstance gives me a debug assertion for nsNativeComponentLoader > being not thread safe !!!
That assertion only tests whether there's a threadsafe addref/release implementation for nsNativeComponentLoader. There isn't, but it's easy enough to change the macro. We'd probably prefer to change how we access the component loader list than do that, though, because the atomic refcnting is expensive and CreateInstance is high-traffic. Other than that, and the case where we actually construct a component _loader_ on two threads at the same time -- a lock there wouldn't kill us, if we could restrict it to the creation case, the only other possible races are component registration racing with creation and scraping its knee on dhash growth and reallocation. Not sure it's worth fixing that the "easy" way, because it will reintroduce pervasive locking costs to the CI path, when we should probably rendezvous with all non-main threads via the XPCOM thread event queue and proxy all registrations to the main thread. Component registration is extremely rare, and we want to push all costs to that uncommon path. So in short: I wouldn't sweat the assertions. If you see a crash because of this problem, I'll be _very_ surprised. Mike
