Robert O'Callahan wrote:
On Sun, Sep 6, 2009 at 4:55 AM, Chris Jones <cjo...@mozilla.com
<mailto:cjo...@mozilla.com>> wrote:
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
* clear private data
* close tab
* quit UA
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).
* "slow script" timeout
* store-to-disk failure
* crash
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.
I don't like the idea of the spec creating an illusion that's impossible
for browser vendors to maintain.
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).
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.
"Force quit" will interrupt scripts.
Desktop apps have to worry about DB consistency, and DBs for those
provide transactional consistency guarantees. It seems undesirable to
deny them to web apps using localStorage, especially since localStorage
seems more author-friendly than Web Database. (Undesirable excepting
compatibility with existing localStorage impls.) This is a rhetorical
point not necessarily directed at you personally, since I think we're
pretty much on the same page.
Cheers,
Chris
