Closed
Bug 52718
Opened 24 years ago
Closed 22 years ago
componentManager is not reentrant
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: aaronb, Assigned: dougt)
References
Details
(Keywords: helpwanted, topembed+)
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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.
I hit the asert at:
nsComponentManager.cpp lines 403, 513
nsRegistry.cpp lines 341, 1946
Comment 6•24 years ago
|
||
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?
Comment 8•24 years ago
|
||
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
Comment 10•23 years ago
|
||
reasigning warren bugs to default component owners.
Assignee: warren → kandrot
QA Contact: rayw → scc
Target Milestone: mozilla1.0 → ---
Assignee | ||
Updated•23 years ago
|
Target Milestone: --- → mozilla1.1
Assignee | ||
Comment 12•22 years ago
|
||
moving out based on my workload. Yell, if you have a problem.
Keywords: helpwanted
Target Milestone: mozilla1.1alpha → Future
Assignee | ||
Comment 13•22 years ago
|
||
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.
Description
•