componentManager is not reentrant

RESOLVED FIXED in Future

Status

()

Core
XPCOM
P3
normal
RESOLVED FIXED
18 years ago
15 years ago

People

(Reporter: aaronb, Assigned: dougt)

Tracking

({helpwanted, topembed+})

Trunk
Future
x86
Windows 2000
helpwanted, topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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

Comment 1

18 years ago
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.

Comment 2

18 years ago
Created attachment 14756 [details]
Stack trace to the assert

Comment 3

18 years ago
I hit the asert at:
nsComponentManager.cpp lines 403, 513
nsRegistry.cpp lines 341, 1946

Comment 4

18 years ago
also nsCategoryManager.cpp line 152

Comment 5

18 years ago
also mozJSComponentLoader.cpp line 241

Comment 6

18 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

Comment 7

18 years ago
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

17 years ago
Assigning rest of xpcom stuff to myself (from Ray).
Assignee: rayw → warren
Status: ASSIGNED → NEW
Target Milestone: Future → mozilla1.0

Comment 9

17 years ago
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

17 years ago
reasigning warren bugs to default component owners.
Assignee: warren → kandrot
QA Contact: rayw → scc
Target Milestone: mozilla1.0 → ---
(Assignee)

Comment 11

17 years ago
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
(Assignee)

Updated

17 years ago
Blocks: 98283
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla1.1
(Assignee)

Comment 12

16 years ago
moving out based on my workload.  Yell, if you have a problem.
Keywords: helpwanted
Target Milestone: mozilla1.1alpha → Future

Updated

15 years ago
Keywords: topembed+
(Assignee)

Comment 13

15 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
Last Resolved: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.