W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

[whatwg] localStorage mutex - a solution?

From: Rob Ennals <rob.ennals@gmail.com>
Date: Tue, 24 Nov 2009 15:12:58 -0800
Message-ID: <f3fb55dd0911241512y1e556137l65e7ea2a781fe76@mail.gmail.com>
Yes. I think that *any* DOM operation, including getElementById should
be allowed to release the storage mutex. If we start specifying
particular categories of API that do or do not release the mutex then
thing will just get confusing, or we will find that we have missed
something important.

The basic rule of thumb should be that if you want to do an atomic
storage operation then you do the following:

1.) Gather all the data that you want to use in your storage
transaction (using whatever DOM call you need)
2.) Perform a sequence of storage operations, not interrupted by any
calls to any API or external library.

This is consistent with the way that systems programmers write
concurrent sections. You gather all your data using whatever
potentially-blocking APIs you need (e.g. opening files), and then hold
your lock for as brief a period of time as possible while doing the
updates you need.

If you run your browser in "super-warnings-enabled" mode then you
could have it warn you if you did anything remotely suspect between
calls to localStorage (e.g. calling a function defined by an external
javascript file or calling an API).

As you say, from a programmers point of view, it would be much nicer
if programmers could use whatever APIs they liked, without having to
worry about losing the storage mutex, however, as we have seen earlier
in this list, that isn't something that the browser vendors believe
they can implement. Some operations unavoidably *have* to release the
storage mutex, and it is surprisingly difficult to specify what
operations these are, or when they might be called.

If we are going to fix the current spec, and give users something that
they can understand, then I see little alternative but to tell them
that *all* APIs and external libraries may release the storage mutex.
It isn't perfect, but it does at least give users an invariant that
they can understand, that they can be sure will always hold, and that
can be implemented by all browsers. Moreover, it allows a programmer
to do essential basic things like implement a test and set lock.


-Rob


On Tue, Nov 24, 2009 at 2:06 PM, Benjamin Smedberg
<bsmedberg at mozilla.com> wrote:
> On 11/23/09 6:13 PM, Rob Ennals wrote:
>> 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?
>
> At the most extreme, then, the implementer could choose to release the
> storage mutex at any DOM operation, such as .getElementById? If that's not
> what you mean, then what set of APIs are we actually talking about
> programmers needing to avoid? This seems like a fundamentally confusing
> model for web programmers. It also seems like a deep mistake to say that
> calling into jQuery means you no longer have consistency guarantees.
>
> Given that libraries may be used to emulate HTML5 features which have not
> yet been implemented by browsers, even referencing seemingly-safe global
> names could end up causing the browser to release the storage mutex!
>
> --BDS
>
Received on Tuesday, 24 November 2009 15:12:58 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:19 UTC