threadsafe xpconnect objects need nsIClassInfo::THREADSAFE

RESOLVED DUPLICATE of bug 280236

Status

()

RESOLVED DUPLICATE of bug 280236
18 years ago
14 years ago

People

(Reporter: jband_mozilla, Assigned: dbradley)

Tracking

Trunk
mozilla1.7alpha
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 1

18 years ago
You probably meant xpcmodule.cpp.
(Assignee)

Updated

18 years ago
Target Milestone: --- → mozilla1.0
(Assignee)

Updated

17 years ago
Target Milestone: mozilla1.0 → mozilla0.9.8
(Assignee)

Comment 2

17 years ago
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
(Reporter)

Comment 3

17 years ago
We certainly mean (1).
(Assignee)

Comment 4

17 years ago
Moving to 0.9.9
Target Milestone: mozilla0.9.8 → mozilla0.9.9
(Assignee)

Comment 5

17 years ago
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
(Reporter)

Comment 6

17 years ago
Sure fix crashers. This bug is no big deal.
(Assignee)

Comment 7

17 years ago
retargetting to post 1.0 mozilla again
(Assignee)

Comment 8

17 years ago
Retargetting to the proper post 1.0 milestone (really this time)
Target Milestone: mozilla1.1 → mozilla1.2
(Assignee)

Comment 9

16 years ago
Moving out to 1.3. If this needs to be in before 1.3 please comment.
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
(Assignee)

Comment 10

16 years ago
Moving to 1.4 Alpha
Target Milestone: mozilla1.3alpha → mozilla1.4alpha
(Assignee)

Comment 11

16 years ago
Moving out
Target Milestone: mozilla1.4alpha → mozilla1.5alpha
(Assignee)

Updated

16 years ago
Target Milestone: mozilla1.5alpha → mozilla1.5beta
(Assignee)

Comment 12

16 years ago
Moving out, speak up if you believe this needs to be considered for 1.5b
Target Milestone: mozilla1.5beta → mozilla1.6alpha
(Assignee)

Comment 13

15 years ago
Moving out
Target Milestone: mozilla1.6alpha → mozilla1.7alpha

Updated

15 years ago
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).

Comment 15

14 years ago
*** 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
(Assignee)

Comment 16

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