Add MOZ_INLINE_DECL_REFCOUNTING and MOZ_INLINE_DECL_THREADSAFE_REFCOUNTING to RefPtr.h and replace the usages of RefCounted with those

NEW
Unassigned

Status

()

Core
MFBT
4 years ago
3 years ago

People

(Reporter: Ehsan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
I'm thinking of making those macros fall back to the NS_ versions inside libxul and provide an identical version outside of it, and try to remove RefCounted by replacing the remaining usages with those macros.

I think I'm going to focus on the mozglue/mozalloc consumers first, and then try to figure out the mozglue ones.

What do you all think about this plan?
(Reporter)

Updated

4 years ago
Blocks: 991812
After bug 1097740 lands, it looks like we have RefCounted<> usage fairly well contained:

- gfx/2d/ contains a few uses, along with a lone use in gfx/gl/SharedSurface.h;
- mozglue/linker/ uses it, and even specializes RefCounted<>, which sounds hard to do with macros;
- memory/mozalloc/VolatileBuffer.h;
- and the few references to it in MFBT itself, notably WeakPtr.

I would like to understand the uses in gfx/ better; does the standalone Moz2D build pull in the MFBT headers, too?  Or does it do something different?

If we can figure out how to make the usages in gfx/ more-or-less self-contained, I think sticking RefCounted<> in mozilla::detail:: is sufficient for the few remaining consumers, and will ideally serve as enough of a deterrent for future would-be refcounters.
Flags: needinfo?(jmuizelaar)
(In reply to Nathan Froyd (:froydnj) from comment #1)
> 
> I would like to understand the uses in gfx/ better; does the standalone
> Moz2D build pull in the MFBT headers, too?  Or does it do something
> different?

Yes it pulls in MFBT headers.
Flags: needinfo?(jmuizelaar)
You need to log in before you can comment on or make changes to this bug.