Remove vestigial threading goop from XPConnect

RESOLVED FIXED in mozilla29

Status

()

Core
XPConnect
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: bholley, Assigned: bholley)

Tracking

(Blocks: 1 bug)

unspecified
mozilla29
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

6 years ago
Once bug 755255 lands, there's a lot of easy cleanup work that can be done. A big part of this is the removal of the map locks, which should give us a free performance boost. At the moment I'm guessing I can do it all in one patch stack, but I may split something off if it turns out that there's a bigger task in there somewhere.
(Assignee)

Updated

5 years ago
Duplicate of this bug: 937152
Depends on: 937152
Depends on: 770535
(Assignee)

Comment 2

5 years ago
The only thing I really see left to do here is to remove a few threadsafe things from XPConnect. Andrew, can you think of anything else?
Here are a few things I've come across:
- NS_DECL_THREADSAFE_ISUPPORTS
- NS_INTERFACE_MAP_END_THREADSAFE
- nsXPConnect::FindMainThread() is undefined and unused

I'm not really sure what to do with
    bool ClassIsThreadSafe()          GET_IT(THREADSAFE)
    bool ClassIsMainThreadOnly()      GET_IT(MAIN_THREAD_ONLY)
in XPCWrappedNativeProto.
(Assignee)

Comment 4

5 years ago
(In reply to Andrew McCreight [:mccr8] from comment #3)
> I'm not really sure what to do with
>     bool ClassIsThreadSafe()          GET_IT(THREADSAFE)

This is unused now.

>     bool ClassIsMainThreadOnly()      GET_IT(MAIN_THREAD_ONLY)

I think this and the corresponding check in wrapper reparenting can just go away.
Depends on: 959484
Depends on: 960715
Hooray!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
You need to log in before you can comment on or make changes to this bug.