Robert O'Callahan wrote:
On Sat, Sep 5, 2009 at 10:22 AM, Chris Jones <cjo...@mozilla.com
<mailto:cjo...@mozilla.com>> wrote:
And if the intention is to make scripts appear to run atomically,
then I think there are better ways to specify that than storage mutex.
That sounds good, how?
My OP is my weak attempt at getting closer to this. "Weak" because it's
still rather imperative rather than declarative, but that's in the style
of the rest of HTML5. If I could start from scratch, I would define
run-to-completion semantics (which I love, BTW) in terms of global state
visible to script and a happens-before relation on events that might
change that state. But it's not clear to me that a
Java-memory-model-type spec would be better for the web than a spec like
HTML5's.
My problem with storage mutex boils down to the fact that by the
letter of the spec, a script can lock out the UA indefinitely by
just reading a cookie.
What do you mean "lock out the UA"?
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
* "slow script" timeout
* store-to-disk failure
* crash
For those cases, IMHO transactional semantics is better because it gives
scripts the guarantee that operations on localStorage are atomic. In
the "secret-storage-mutex world," if you agree that the cases above
imply that the UA will have to interrupt scripts, then it's possible for
scripts to make changes to localStorage that are only partially applied,
going by the letter of the storage mutex spec. I think that for sites
that would care (e.g. gmail), partially-applied changes are a bad thing.
And as I argued in the OP, I think localStorage should be designed
only with sites like gmail in mind.
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).
Transactional semantics seems to be a better abstraction, and an
ancillary benefit is that it's much easier to implement to boot.
Though even if it were harder to implement, I would still argue for it.
I agree with you. However, there is still the compatibility issue. (Some
people may also argue that what we currently have is simpler for authors
than any explicit transactional API --- personally I'm unsure if that
matters.)
API breakage is a problem, but does my proposal to only sort of break
compatibility through pretending not to offer window.localStorage until
window.beginTransaction is accessed not satisfy?
Cheers,
Chris
