Closed Bug 81879 Opened 23 years ago Closed 19 years ago

threadsafe xpconnect objects need nsIClassInfo::THREADSAFE

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 280236
Milestone:
mozilla1.7alpha

People

(Reporter: jband_mozilla, Assigned: dbradley)

References

Details

Native objects in the xpconnect runtime that can be wrapped for use from JS and 
which are threadsafe should have nsIClassInfo with the THREADSAFE flag set.

In many cases this is just a matter fo modifying the nsModuleComponentInfo line 
for the class in xpccmodule.cpp. In the cases where a factory is not registered 
(e.g. Components, Components.interfaces, etc) this will probably mean adding a 
simple implementation of nsIClassInfo and adding the getter for the 
classinfo object to the instance object's QI implementation.
Status: NEW → ASSIGNED
You probably meant xpcmodule.cpp.
Target Milestone: --- → mozilla1.0
Target Milestone: mozilla1.0 → mozilla0.9.8
jband, I recently became aware that there are two definitions of thread safety
floating around. I wanted to double check what your view is so I can properly
evaulate the classes in question.

1. It means that multiple threads can execute any method on an object and the
object controls the synchronization of its state
2. It means that an instance is threadsafe as long as it accesses no global
variable and does not contain static data members (or their access is
synchronized). Two instances can be executed on two different threads, but a
single instance cannot be exposed to more than one thread.

Given the checks I see, it looks like definition 1 is in play here.

For a detailed discussion of the issues, the thread in comp.lang.c++.moderated
starts here.

http://groups.google.com/groups?q=g:thl3936537526d&hl=en&selm=KhJU7.235532%243d2.11299461%40bgtnsc06-news.ops.worldnet.att.net
We certainly mean (1).
Moving to 0.9.9
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Moving out. If anyone thinks this should be in before 1.0 let me know I can get
the change in, but I've got a lot of frequent to occasional crashers that I'd
rather be looking at in the short time left.
Target Milestone: mozilla0.9.9 → mozilla1.1
Sure fix crashers. This bug is no big deal.
retargetting to post 1.0 mozilla again
Retargetting to the proper post 1.0 milestone (really this time)
Target Milestone: mozilla1.1 → mozilla1.2
Moving out to 1.3. If this needs to be in before 1.3 please comment.
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
Moving to 1.4 Alpha
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
Moving out
Target Milestone: mozilla1.4alpha → mozilla1.5alpha
Target Milestone: mozilla1.5alpha → mozilla1.5beta
Moving out, speak up if you believe this needs to be considered for 1.5b
Target Milestone: mozilla1.5beta → mozilla1.6alpha
Moving out
Target Milestone: mozilla1.6alpha → mozilla1.7alpha
Depends on: 234703
I'm getting lots of threadsafety whining while trying to construct objects on other threads using 
Components, even though Components itself appears to be threadsafe (at least the nsISupports piece of it 
is).
*** This bug has been marked as a duplicate of 280236 ***

*** This bug has been marked as a duplicate of 280236 ***
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Try and provide a comment as to why this is a dupe. It was unclear until I
looked at the patch why this was a dupe of bug 280236.

Personally I'd rather not lump these two together and break out the part of that
patch that deals with nsIClassInfo. If for whatever reason we need to back out
bug 280236 specific stuff, it's going to tied to the nsIClassInfo part that may
not need to be pulled out.
You need to log in before you can comment on or make changes to this bug.