Using preferences off the main thread now asserts
It's taken over 3 years, but Bug 619487 is now fixed, and the preferences service will assert (fatally) if you try to use it off the main thread. This is currently disabled on b2g while I track down the last misuses of the pref service in b2g-specific code. After the next train leaves I plan to upgrade these to release mode assertions so we can start catching addons that misuse the pref service. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using preferences off the main thread now asserts
Huzzah! Well done Kyle. On Mar 6, 2014 8:20 AM, Kyle Huey m...@kylehuey.com wrote: It's taken over 3 years, but Bug 619487 is now fixed, and the preferences service will assert (fatally) if you try to use it off the main thread. This is currently disabled on b2g while I track down the last misuses of the pref service in b2g-specific code. After the next train leaves I plan to upgrade these to release mode assertions so we can start catching addons that misuse the pref service. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using preferences off the main thread now asserts
Thanks for doing this. However I feel like our options for code that need preferences off the main thread are a bit poor. The first option is to send an IPC message to the main thread but that has very poor performance, requires a lot of boilerplate code and either an sync message or async+restructuring the control flow. The second option is to read the preferences on startup and have them as read-only shared globals like gfxPrefs: http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxPrefs.h#106 Ideally I'd like to only read in the preference when/if I need to access it, particularly as we have increasingly more code living off the main thread. On Thu, Mar 6, 2014 at 11:20 AM, Kyle Huey m...@kylehuey.com wrote: It's taken over 3 years, but Bug 619487 is now fixed, and the preferences service will assert (fatally) if you try to use it off the main thread. This is currently disabled on b2g while I track down the last misuses of the pref service in b2g-specific code. After the next train leaves I plan to upgrade these to release mode assertions so we can start catching addons that misuse the pref service. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
IID Abuse
Because of the way GetIID/NS_GET_IID works, it's not very easy to get the compiler to tell you when you're doing it wrong. So far I've come up with a way to get the linker to do it. I'm trying to get the compiler to do it, but the results aren't perfect. However along the way I have noticed some common mistakes regarding IIDs. The most popular mistake was to include a concrete class in NS_IMPL_ISUPPORTS; nsSupportsWeakReference was typical. I noticed a couple of places that queried for a concrete class which didn't have its own IID, which means that you end up querying for the base interface instead. I noticed some code that appeared to be adding IIDs to concrete classes just so that nsCOMPtr would compile. (In fact the objects in question should probably have been managed using nsAutoPtr instead of refcounting.) There were some cases which surprised me weren't already compile or link errors: * Defining the IID in a random cpp file instead of the header that declares it. (Presumably the template that creates the storage for the IID manages to get instantiated in one cpp file which allows it to get linked to by the other consumers.) * nsRDFQuery.h declares the IID for the nsITemplateRDFQuery, but defines it for nsRDFQuery. (I'm wildly guessing here that the compiler sees the inherited declaration and somehow defines it?) * nsIFrame.h manages to use nsIPresShell in several ways using nothing more than a forward reference. (Except for pointers and references, I always thought this was a compile error.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using preferences off the main thread now asserts
On Thursday 2014-03-06 19:52 -0800, Nicholas Nethercote wrote: On Thu, Mar 6, 2014 at 8:20 AM, Kyle Huey m...@kylehuey.com wrote: It's taken over 3 years, but Bug 619487 is now fixed, and the preferences service will assert (fatally) if you try to use it off the main thread. Out of curiosity, what's the benefit of this? Is it just a correctness issue? The bug didn't have much detail. It's an issue of not crashing when trying to manipulate the same hashtable from two different threads at the same time without any sort of locking. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
