On Thu, Dec 27, 2012 at 1:56 PM, Neil <n...@parkwaycc.co.uk> wrote: > Jonas Sicking wrote: > >> On Dec 18, 2012 4:15 AM, "Neil" <n...@parkwaycc.co.uk> wrote: >> >>> >>> While investigating the possibility of switching nsCOMArray away from >>> nsVoidArray it occurred to me that nsCOMArray takes steps to ensure internal >>> consistency before releasing removed elements; this is because it's >>> potentially possible for Release() to invoke arbitrary code; if this code >>> ends up attempting to access the original nsTArray then all bets are off. I >>> think we've had reentrancy bugs before so we could have them again. >>> >> Yes, though this is not specific to nsTArrays >> > We don't exactly have a large number of array types that we use to store > owning references to XPCOM objects...
This can happen *any* time you call a dtor. So nsTArrays which contain objects rather than object references, I.e. any type of nsTArray<Foo> (rather than nsTArray<Foo*>). And any time we nsTArrays are containing smartpointers, i.e. nsTArray<nsAutoPtr<Foo>>, nsTArray<nsRefPtr<Foo>> and nsTArray<nsCOMPtr<Foo>>. And any time we structs which contain any of the above types, i.e. nsTArray<StructContainingInlineObjectOrSmartPointer>. There's nothing special about XPCOM objects here. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
