{"id":159,"date":"2013-04-10T20:51:14","date_gmt":"2013-04-10T20:51:14","guid":{"rendered":"http:\/\/blog.mozilla.org\/nfroyd\/?p=159"},"modified":"2013-04-10T20:51:14","modified_gmt":"2013-04-10T20:51:14","slug":"mozistorageservice-the-main-thread-and-you","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nfroyd\/2013\/04\/10\/mozistorageservice-the-main-thread-and-you\/","title":{"rendered":"mozIStorageService, the main thread, and you"},"content":{"rendered":"

Bug 836493<\/a> landed on inbound today.\u00a0 An additional constraint is now enforced on mozIStorageService<\/code>: the initial reference to it must be obtained on the main thread.\u00a0 However, all references after the first can be obtained on any thread.<\/p>\n

Seems awfully complicated; what do we gain from that change?\u00a0 Two things.\u00a0 The first is that there was a race in the initialization of the storage service.\u00a0 Some bits of storage service initialization, like accessing preferences, could only be done on the main thread.\u00a0 If the storage service was initialized on a non-main thread, it dispatched an event to the main thread to perform those initialization tasks.\u00a0 Therefore, you might end up with a sequence of events like:<\/p>\n

    \n
  1. Non-main thread requests the storage service.<\/li>\n
  2. Storage service starts initialization, dispatches event to the main thread.\u00a0 This event can’t run until after step 4, for various reasons (thread scheduling, backed-up event queue on the main thread, etc. etc.).<\/li>\n
  3. Storage service initialization returns, handing an (incompletely initialized) object back to the caller.<\/li>\n
  4. Caller uses the not-yet initialized storage service, leading to possible problems.<\/li>\n<\/ol>\n

    Additionally, the storage service builds an SQLite VFS<\/acronym><\/a> for handling things like quota management.\u00a0 This building happens on the calling thread and accesses prefs<\/a> to make profiles that live on networked storage robust<\/a>.\u00a0 That’s a non-main thread preferences use which could lead to crashes.\u00a0 That needs to go away so we can enforce main thread-only preferences usage<\/a>.<\/p>\n

    Even though this change might make programming slightly more inconvenient, the end result is safer code for our users and (eventually) better enforcement of good coding practices.<\/p>\n","protected":false},"excerpt":{"rendered":"

    Bug 836493 landed on inbound today.\u00a0 An additional constraint is now enforced on mozIStorageService: the initial reference to it must be obtained on the main thread.\u00a0 However, all references after the first can be obtained on any thread. Seems awfully complicated; what do we gain from that change?\u00a0 Two things.\u00a0 The first is that there […]<\/p>\n","protected":false},"author":320,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/159"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/users\/320"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/comments?post=159"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/159\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/media?parent=159"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/categories?post=159"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/tags?post=159"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}