Closed Bug 52718 Opened 24 years ago Closed 22 years ago

componentManager is not reentrant

Categories

(Core :: XPCOM, defect, P3)

x86
Windows 2000
defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: aaronb, Assigned: dougt)

References

Details

(Keywords: helpwanted, topembed+)

Attachments

(1 file)

An attempt to create a component instance outside the main thread raises the assertion: ###!!! ASSERTION: nsComponentManagerImpl not thread-safe: 'owningThread == NS_CurrentThread()', file c:\mozilla_source\mozilla\xpcom\base\nsDebug.cpp, line 490
I'm tripping this too. My code needs to create JS components from other than the main thread. These component instances are only used by the thread that creates them. Component manager needs to be thread safe. I don't see that there is any real way to avoid this. Switching to NS_IMPL_THREADSAFE_ISUPPORTS() will make the assert go away but the code needs to be checked for thread safety.
Attached file Stack trace to the assert (deleted) —
I hit the asert at: nsComponentManager.cpp lines 403, 513 nsRegistry.cpp lines 341, 1946
also nsCategoryManager.cpp line 152
also mozJSComponentLoader.cpp line 241
It seems clear from this assertion that component manager was not designed to be thread safe. The cost of making it usable outside the primary thread needs to be weighed for the future.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
Thread safe component creation is critical for a server environment. I might as well make my web server single threaded if I have to marshal every create instance call off to the main thread. This totally prohibits building a scalable server based on XPCOM. I don't this this is a bad as it looks. There are comments all over the component loader and registry code about threading issues. Obviously someone has already looked into this. The asserts may simple be a bogus side effect of changing NS_IMPL_ISUPPORTS. Could the authors of these components verify if the problem is simply not having changed NS_IMPL_ISUPPORTS to NS_IMPL_THREADSAFE_ISUPPORTS where needed, or if these components really aren't threadsafe?
Assigning rest of xpcom stuff to myself (from Ray).
Assignee: rayw → warren
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla1.0
I broke this bug down into four more acurate ones: 54633 nor P3 All rayw@netscape.com UNCO nsCategoryManagerFactory is not threadsafe 54635 nor P3 All rayw@netscape.com UNCO nsRegistryFactory is not threadsafe 54636 nor P3 All rayw@netscape.com UNCO nsRegistry is not threadsafe 54638 nor P3 All rayw@netscape.com UNCO nsComponentManagerImpl is not threadsafe 54639 nor P3 Oth rayw@netscape.com UNCO nsCategoryManager is not threadsafe You can close this one when the other four are opened. JBand has already fixed mozComponentLoader
reasigning warren bugs to default component owners.
Assignee: warren → kandrot
QA Contact: rayw → scc
Target Milestone: mozilla1.0 → ---
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
Blocks: 98283
Target Milestone: --- → mozilla1.1
moving out based on my workload. Yell, if you have a problem.
Keywords: helpwanted
Target Milestone: mozilla1.1alpha → Future
Keywords: topembed+
This is and has been fix for a while. You should have no problem creating a component via the component manager from a seperate thread. Most of the problems were fixed when 48888 landed. Marking fixed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: