On Mon, Jul 31, 2017 at 4:53 PM, smaug <sm...@welho.com> wrote: >> And on the topic of memory management: >> >> DOM nodes themselves obviously have to be able to deal with multiple >> references to them, but otherwise we have a lot of useless use of >> refcounting attributable to the 1998/1999 mindset of making everything >> an nsIFoo. In cases where mozilla::UniquePtr would suffice and >> nsCOMPtr isn't truly needed considering the practical ownership >> pattern, making the Rust objects holdable by mozilla::UniquePtr is >> rather easy: mozilla::Decoder and mozilla::Encoder are real-world >> examples. > > Reference counting is needed always if both JS and C++ can have a pointer to > the object.
Being able to have JS point to a lot of things is part of the original "everything is an nsIFoo" XPCOM mindset. For example, the types that mozilla::Decoder and mozilla::Encoder replaced were not scriptable but had XPCOM reference counting. They were always used in a manner where mozilla::UniquePtr would have sufficed in C++ and didn't work from JS anyway. > And UniquePtr makes it harder to ensure some object stays alive during a > method call, say, if a member variable is > UniquePtr. With refcounting it is always easy to have local strong > reference. When UniquePtr points to a Rust object, there's the mitigation that introducing a call from Rust to C++ involves more intentionality than adding another C++ to C++ call, so it's easier to notice when a call to C++ that might release the C++ object that holds the UniquePtr is introduced. For example, mozilla::Decoder and mozilla::Encoder never call to C++ code, so it's easy to reason that such leaf code can't accidentally delete what `self` points to. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
