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.
You probably meant xpcmodule.cpp.
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
Target Milestone: mozilla1.4alpha → mozilla1.5alpha
Moving out, speak up if you believe this needs to be considered for 1.5b
Target Milestone: mozilla1.5beta → mozilla1.6alpha
Target Milestone: mozilla1.6alpha → mozilla1.7alpha
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
Last Resolved: 14 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.