You've now sent 3 "please unsubscribe me" posts -- I don't think those have any effect, aside from spamming everyone else on the list.
If you want to unsubscribe, you can do so via this link (which is included at the bottom of every email you receive from this list): https://lists.mozilla.org/listinfo/dev-platform Unsubscription instructions are available at the bottom of that page. ~Daniel On 04/01/2015 06:39 PM, Alex Webster wrote: > Please unsubscribe me > On Wed, Apr 1, 2015 at 9:26 PM Jonas Sicking <jo...@sicking.cc> wrote: > >> On Thu, Apr 2, 2015 at 3:00 AM, ben turner (bent) >> <bent.mozi...@gmail.com> wrote: >>> On Wednesday, April 1, 2015 at 2:12:40 PM UTC-7, somb...@gmail.com >> wrote: >>>> - Crash-wise, are we talking about only the parent process crashing, or >>>> are we talking about the child process crashing too? >>> >>> I was talking just about the parent process. If the child process >> crashes then whether or not the transaction is durable depends on whether >> or not the parent received the commit message and processed it (otherwise >> we automatically abort any outstanding transactions). That behavior is >> unchanged. >> >> That doesn't sound entirely right. >> >> As soon as the child process received the last "success" event for a >> given request in a transaction, and we've sent the "go ahead and >> commit" message to the parent, then I would expect that it's ok for >> the child to crash at any point. This might match what you are saying. >> >> However the more important question that I believe Andrew is asking, >> is if we receive a "commit" event, what can then crash without there >> being a dataloss. My understanding is that at that point both the >> child and the parent can crash. As long as the kernel doesn't panic, >> or the battery runs out or is removed, the data will be written. >> >> I.e. once the "commit" event fires, the data has been transferred to >> the OS, and as long as the OS shuts down cleanly, or has time to >> flush, the data will be safe. >> >>>> 1. Device shutdown via the UI >>> >>> This should be fine, we will flush to disk before actually powering down. >>> >>>> 2. User pulls the battery. >>>> 3. Hardware-shutdown via long-hold of the power button. >>>> 4. Device runs out of power. >>> >>> These three cases may fail to flush the data to disk, and if so when we >> restart the transaction will be rolled back. >>> >>>> For 3: long-power-button-hold it seems like >>>> depending on how extensively things are wedged, we could notice at say 6 >>>> seconds that we're headed for a shutdown and try to trigger an fsync and >>>> put a stop to new transactions. >>> >>> That sounds reasonable, assuming we get that notification at the gecko >> layer? I am not sure what kind of info we get when long-presses happen. >> >> I would think that when long-press happens, the CPU simply receives a >> reset signal. So it's equivalent to pulling the battery and putting it >> back. >> >> But maybe the OS is sent a signal a few seconds prior to that which >> would encourage it to flush. I'm not sure. >> >>>> For 4: low-power, ideally there's just >>>> a point that the device decides it's not safe to operate and shuts >>>> itself down, and that's slightly before it would result in IndexedDB >>>> badness. >>> >>> I don't know, but if it goes through normal shutdown then we will be >> fine. >> >> I'm pretty sure this results in the OS getting shut down cleanly, and >> so will flush any data it still holds. I.e. the data should be safe >> given my answer at the top. >> >>>> My main question is what is a realistic risk model for power loss/crash >>>> and are there mitigations we can put in place to reduce the risk to >>>> users? >>>> ... >>>> The issue there is how long the IndexedDB window of vulnerability is. >>> >>> Flushing happens automatically after the database is idle (i.e. no >> active transactions) for 2 seconds at present. If the database never goes >> idle for that long then we continue to journal until the WAL size exceeds >> 20MB on desktop or 10MB on mobile. >> >> But prior to that flushing the data has been write()ten, right? So the >> OS will take care of flushing it eventually as long as it's shut down >> cleanly. >> >> / Jonas >> _______________________________________________ >> 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
