W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [chromium-html5] LocalStorage inside Worker

From: Glenn Maynard <glenn@zewt.org>
Date: Thu, 6 Jan 2011 18:47:21 -0500
Message-ID: <AANLkTi=DNwyhyNHowMuVj6+tfUHpmc+RKtAXG0Ohr1Sf@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Jeremy Orlow <jorlow@chromium.org>, Felix Halim <felix.halim@gmail.com>, public-webapps WG <public-webapps@w3.org>
On Thu, Jan 6, 2011 at 5:11 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> Unfortunately this is not possible. Since localStorage is
> synchronously accessed, if we allowed workers to access it that would
> mean that we no longer have a shared-nothing-message-passing threading
> model. Instead we'd have a shared memory threading model which would
> require locks, mutexes, etc.

This already exists, when multiple instances of a page access
localStorage.  I don't see how workers are any different.

I'm aware that this is technically a bug, since it ignores the storage
mutex required by the spec--but it doesn't seem like browsers have any
intention of implementing that.  It seems like the spec should
describe something that will actually be implemented in browsers.  In
the end, it seems like the real-world implementations of localStorage
lose nothing by allowing workers access to it; it's only a loss for
the theoretical version in the spec that nobody is implementing.

Unless vendors have changed their mind on the mutex and are starting
to implement it, anyway.

> That said. As I have suggested before (don't remember if it was here
> or on the whatwg list), if we create a new version of localStorage,
> where you can only get a reference to the localStorage object
> asynchronously, then we should be fine. So something like:
> var s;
> getBetterStorage(function(storage) {
>  storage.foo += storage.bar;
>  storage.baz = "hello world";
>  storage.text = "she sells sea schells by the sea shore";
>  s = storage;
>  setTimeout("runlater", 10);
> });
> function runlater() {
>  s.foo = "bar"; // throws an exception
> }
> would work fine, both in workers and outside them. It would also
> remove the racyness that many localStorage implementations have since
> they don't implement the storage mutex.

This would require that only one async storage callback (for a
particular Storage object) can be running at any one time.  That means
browsers would have to lock the storage object to prevent that--and
that's essentially the same as the current mutex requirement.  In
other words, I suspect browsers wouldn't implement it.

Glenn Maynard
Received on Thursday, 6 January 2011 23:48:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:15 UTC