Closed
Bug 1034920
Opened 10 years ago
Closed 10 years ago
nsNativeModuleLoader does not need to be a refcounted class
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
mozilla34
People
(Reporter: bjacob, Assigned: mccr8)
References
Details
Attachments
(3 files)
(deleted),
patch
|
froydnj
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
froydnj
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
froydnj
:
review+
|
Details | Diff | Splinter Review |
In bug 1028588 we removed dangerous public destructors of XPCOM-refcounted classes outside of a finite whitelist, see HasDangerousPublicDestructor. Now we are going over the entries in this whitelist.
One of them is: nsNativeModuleLoader
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → continuation
Assignee | ||
Comment 1•10 years ago
|
||
This is ugly. nsComponentManagerImpl has a field with type nsNativeModuleLoader (not a pointer). nsNativeModuleLoader implements refcounting by forwarding it to nsComponentManagerImpl::gComponentManager. The only thing that ever addrefs nsNativeModuleLoader as far as I can see is some runnable.
The nsNativeModuleLoader field can't just be turned into a ref ptr as this causes a "cycle" because it just addrefs gComponentManager, unless we just manually clear the native module loader field at some point in shutdown. Maybe that's not so bad.
Assignee | ||
Comment 2•10 years ago
|
||
I kind of want to disaggregate nsNativeModuleLoader (there are only a handful of classes that use it), by making the runnable directly hold onto gComponentManager directly, but I'm nervous that it will make things too fragile.
Assignee | ||
Updated•10 years ago
|
Summary: Remove dangerous public destructor of nsNativeModuleLoader → nsNativeModuleLoader does not need to be a refcounted class
Assignee | ||
Comment 3•10 years ago
|
||
Attachment #8463430 -
Flags: review?(nfroyd)
Assignee | ||
Comment 4•10 years ago
|
||
Attachment #8463431 -
Flags: review?(nfroyd)
Assignee | ||
Comment 5•10 years ago
|
||
It is only used as a field of gComponentManager, so the full nsISupports and COM treatment isn't needed.
Attachment #8463433 -
Flags: review?(nfroyd)
Assignee | ||
Comment 6•10 years ago
|
||
Updated•10 years ago
|
Attachment #8463430 -
Flags: review?(nfroyd) → review+
Updated•10 years ago
|
Attachment #8463431 -
Flags: review?(nfroyd) → review+
Comment 7•10 years ago
|
||
Comment on attachment 8463433 [details] [diff] [review]
part 3 - nsNativeModuleLoader doesn't need to implement ModuleLoader.
Review of attachment 8463433 [details] [diff] [review]:
-----------------------------------------------------------------
::: xpcom/components/nsNativeModuleLoader.cpp
@@ +89,5 @@
> return NS_OK;
> }
>
> + nsRefPtr<nsComponentManagerImpl> mManager;
> + nsNativeModuleLoader* mLoader;
Hooray for more explicit lifetime management.
::: xpcom/components/nsNativeModuleLoader.h
@@ -11,3 @@
> #include "nsDataHashtable.h"
> #include "nsHashKeys.h"
> -#include "mozilla/Module.h"
All these headers just to cargo-cult FileLocation and the nsISupports bits? Ugh.
Attachment #8463433 -
Flags: review?(nfroyd) → review+
Assignee | ||
Comment 8•10 years ago
|
||
> All these headers just to cargo-cult FileLocation and the nsISupports bits? Ugh.
Yeah it is awesome.
remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/ccfca130bbe3
remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/e814aa7bab58
remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/b84ac541b00e
Comment 9•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ccfca130bbe3
https://hg.mozilla.org/mozilla-central/rev/e814aa7bab58
https://hg.mozilla.org/mozilla-central/rev/b84ac541b00e
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
You need to log in
before you can comment on or make changes to this bug.
Description
•