[whatwg] localStorage mutex - a solution?

The planned model is that if you don't want to lose the storage mutex
then you shouldn't call any code that you didn't write yourself. Any
external library (e.g. jquery) should be assumed to release the
storage mutex. Perhaps that should be made explicit in the spec?

We want to guarantee essential things like "several localStorage ops
in a row are atomic", and make sure any language-level transformations
that people expect to be semantics preserving remain so (e.g. moving
code into a function), while still giving the browser the ability to
release the mutex whenever it might need to.

-Rob


On Sat, Nov 7, 2009 at 12:08 AM, Chris Jones <cjones at mozilla.com> wrote:
> Rob Ennals wrote:
>>
>> Missed out the important final qualifier. Here's take 3:
>>
>> "the user agent MUST NOT release the storage mutex between calls to local
>> storage, except that the user agent MAY release the storage mutex on any API
>> operation /other that a local storage oeration/"
>>
>
> IMHO, this is actually worse than the current proposal of a global mutex :S.
> ?This proposal makes atomicity guarantees not only library-dependent, but
> browser-implementation-dependent. ?For example
>
> ?a = localStorage.x()
> ?jquery.foo()
> ?b = localStorage.y()
>
> If |jquery.foo()| were, say, parsing JSON or determining selector matching,
> it might involve "browser API calls" in some browser, and in others not.
>
> Worse, if |jquery.foo()| involves accessing browser-managed things like
> computed DOM attributes, then even in the *same* browser it might result in
> sometimes needing a "browser API call", and sometimes only needing a JS-only
> call. ?(Depending on DOM attribute cache status, if present.)
>
> This of course of depends on the definition of "browser API call", but I
> interpret this as approximately meaning "calling from JS to C++".
>
> These objections are in addition to those made by Jeremy Orlow concerning a
> script-managed, possibly cross-process mutex, which I also find unpleasant.
>
> Cheers,
> Chris
>

Received on Monday, 23 November 2009 15:13:43 UTC