81879 - threadsafe xpconnect objects need nsIClassInfo::THREADSAFE

Status: RESOLVED DUPLICATE of bug 280236

(Core :: XPConnect, defect)

Description

[John Bandhauer]

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.

Comment 1

[Patrick C. Beard]

You probably meant xpcmodule.cpp.

Comment 2

[David Bradley]

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

Comment 3

[John Bandhauer]

We certainly mean (1).

Comment 4

[David Bradley]

Moving to 0.9.9

Comment 5

[David Bradley]

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.

Comment 6

[John Bandhauer]

Sure fix crashers. This bug is no big deal.

Comment 7

[David Bradley]

retargetting to post 1.0 mozilla again

Comment 8

[David Bradley]

Retargetting to the proper post 1.0 milestone (really this time)

Comment 9

[David Bradley]

Moving out to 1.3. If this needs to be in before 1.3 please comment.

Comment 10

[David Bradley]

Moving to 1.4 Alpha

Comment 11

[David Bradley]

Moving out

Comment 12

[David Bradley]

Moving out, speak up if you believe this needs to be considered for 1.5b

Comment 13

[David Bradley]

Moving out

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

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).

Comment 15

[timeless]

*** This bug has been marked as a duplicate of 280236 ***

*** This bug has been marked as a duplicate of 280236 ***

Comment 16

[David Bradley]

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.