On Sun, Sep 6, 2009 at 4:55 AM, Chris Jones <span dir="ltr"><<a href="mailto:cjones@mozilla.com">cjones@mozilla.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I mean prevent the UA from affecting a script's execution.  The cases I've thought of so far where we will probably have to break storage-mutex semantics are<br>
<br>
  * clear private data<br></blockquote><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
  * close tab<br>
  * quit UA<br></blockquote><br>I think these could appear to complete immediately while doing their work asynchronously in the background, given the assumption that content script execution time is bounded (if it takes "too long" we enforce the assumption using the slow-script timeout).<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
  * "slow script" timeout<br>
  * store-to-disk failure<br>
  * crash<br>
<br></blockquote><div><br>In HTML5 we generally take the approach that if a UA is unable to satisfy spec semantics due to resource limits or other problems in the environment, then it's OK to deviate from the spec. Applying that principle here, we would not need to provide database consistency in the presence of these failures.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">And as I argued in the OP, I think localStorage should be designed only with sites like gmail in mind.<br>
</blockquote><div><br>Yes ... I'm not so sure about that.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I'm beginning to think that this discussion is more about DB consistency than multi-event-loop UAs.  I think it's telling that all of the cases I listed above could arise in single-process Gecko except "clear private data" (and maybe "close tab", not sure).<br clear="all">
</blockquote><div> </div></div>Currently in Gecko "clear private data", "close tab" and "quit" would all wait for running scripts to complete. But indeed, the consistency you want isn't provided by any browser today if the app encounters resource limits or hardware failures. Storing a single key-value pair should be atomic in the case of failure, so apps have to roll-your-own consistency and recovery using that.<br>
<br>Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>