Since Sqlite.jsm calls asyncClose, the actual closing could theoretically take place after profile-before-change, which is bad. We need to plug these calls to asyncClose to AsyncShutdown.profileBeforeChange. This will cause shutdown freezes (or 100% reproducible shutdown crashes once bug 917764 has landed) if the owner of the database calls asyncClose too late, which is certainly better than silent data loss/corruption.

Gps could you handle this?

I think this will do it! Not sure how to test this explicitly...

Comment on attachment 813076 [details] [diff] [review] Use AsyncShutdown in Sqlite.jsm Review of attachment 813076 [details] [diff] [review]: ----------------------------------------------------------------- That looks good to me. I would be slightly more comfortable if that part of the code were written with Task.jsm and we had a try/finally to ensure that we always resolve/reject the promise. What do you think?

Comment on attachment 813076 [details] [diff] [review] Use AsyncShutdown in Sqlite.jsm (In reply to David Rajchenbach Teller [:Yoric] from comment #3) > That looks good to me. > I would be slightly more comfortable if that part of the code were written > with Task.jsm and we had a try/finally to ensure that we always > resolve/reject the promise. > What do you think? I think the current patch accomplishes what we set out to accomplish in a very simple way and any extra code cleanup should be deferred to a followup bug.

Comment on attachment 813076 [details] [diff] [review] Use AsyncShutdown in Sqlite.jsm Review of attachment 813076 [details] [diff] [review]: ----------------------------------------------------------------- Ok, I won't insist.