Last Comment Bug 903093 - Ensure that XPI and AddonRepository JSON is completely written before shutdown
: Ensure that XPI and AddonRepository JSON is completely written before shutdown
Status: RESOLVED DUPLICATE of bug 911621
:
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: unspecified
: All All
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andy McKay [:andym]
Mentors:
Depends on: 911621
Blocks: 853388 853389 911820
  Show dependency treegraph
 
Reported: 2013-08-08 12:21 PDT by :Irving Reid (No longer working on Firefox)
Modified: 2013-09-13 06:51 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image :Irving Reid (No longer working on Firefox) 2013-08-08 12:21:03 PDT
The AddonRepository and XPIDatabase conversion to JSON added asynchronous writes of the databases, which could happen at shutdown time. I'm not sure how strongly we can guarantee that the write has completed before shutdown; we may need to add something (either a nested event loop or a hook in the main event loop) to wait for these writes to complete.

The async writes may start during profile-before-change, and it's possible for there to be a second write. The worst case scenario is:

First write starts
Data is modified again
profile-before-change notification comes
  Flush JSON; queues a promise to start a second write after the
  first write completes
profile-before-change done
First write completes
Second write begins

The more common (but still rare) cases would be for a single write to be in progress when profile-before-change comes, or for a single write to be triggered by profile-before-change.

My understanding, and Yoric should correct me here if necessary, is that when OS.File shuts down (during xpcom-shutdown) it blocks until all in progress writes have finished. This would mean we're safe in every case *except* my worst case scenario above, if what happens is:

Write starts
Data is modified again
profile-before-change
  set up delayed second write
profile-before-change ends
xpcom-shutdown starts
  OS.File blocks until first in-progress write completes
xpcom-shutdown ends
Second write is attempted, but fails because OS.File is gone
Comment 1 User image David Teller [:Yoric] (please use "needinfo") 2013-08-09 07:30:59 PDT
I confirm.
Comment 2 User image :Irving Reid (No longer working on Firefox) 2013-09-13 06:51:30 PDT
Work on this is being done in bug 911621.

*** This bug has been marked as a duplicate of bug 911621 ***

Note You need to log in before you can comment on or make changes to this bug.