On 5/14/13 11:35 AM, Felipe Gomes wrote:
On Friday, May 10, 2013 7:53:01 PM UTC-3, Benjamin Smedberg wrote:
I'm not sure about the rest of this question. But you should not be
performing any I/O after profile-before-change. See
https://wiki.mozilla.org/XPCOM_Shutdown and note that after
profile-before-change, we are working on immediately exiting the browser
and skipping XPCOM shutdown. xpcom-shutdown is definitely too late!
Okay. The code i'm touching does that on xpcom-shutdown but since it'll be
wrong in the future I'll change it while I'm there. (it finishes some pending
async sqlite stmts and rolls back any ongoing transactions).
What prompted the question is that I'm working on a conversion from SQLite
storage to a JSON file. OS.File.writeAtomic provides a good guarantee of data
consistency against crashes etc, and I'm now looking how to guarantee a proper
full flush of the data to disk during shutdown.
Should profile-before-change then be my call to stop accepting changes to the data and
call writeAtomic to flush it? I've seen some code nearby doing it at
quit-application-granted. Or perhaps there's no "correct" answer and it varies
case by case (or anything goes that works and is early enough..)
This sounds very similar to what I ran into with Firefox Health Report.
There is some discussion in
https://bugzilla.mozilla.org/show_bug.cgi?id=722648 and
https://bugzilla.mozilla.org/show_bug.cgi?id=850712.
Generally speaking, you have a queued async operation or set of async
operations that need to complete. However, profile-before-change is
observed before or during those operations. There is a race between
xpcom-shutdown and those async operations finishing.
FHR's solution to this problem is to initiate the shutdown procedure
early during shutdown. We chose quit-application. If this shutdown
sequence (which consists of waiting for async operations initiated or
queued before shutdown started) has not completed by the time
profile-before-change (the last observer before the profile goes away)
is observed, FHR creates a nested event loop during the
profile-before-change handler. This delays shutdown. But it eliminates
race conditions and prevents data corruption. Code at
https://hg.mozilla.org/mozilla-central/file/26ab72bfa9df/services/healthreport/healthreporter.jsm#l445
Performance *really* doesn't like this solution because it can delay
shutdown. However, the last I checked Telemetry, we only had 121 reports
on Nightly and Aurora of this occurring in the past month. This is
because we only create a nested event loop if shutdown hasn't finished
by profile-before-change and unless a major FHR operation was initiated
just before shutdown, there will be no work to do except close the
database handle. If we were buffering data and persistently flushing,
we'd likely be spinning much more since we'd be more likely to have
queued I/O.
I'll conclude by saying that every scenario is different. I highly
recommend you connect with someone on the Perf team for a tailored
recommendation.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
