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

Re: [chromium-html5] LocalStorage inside Worker

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 6 Jan 2011 19:55:21 -0800
Message-ID: <AANLkTinr++PnHhv8ES4pfr+_3G9Z87iH+M-1RjDLG69v@mail.gmail.com>
To: Felix Halim <felix.halim@gmail.com>
Cc: Jeremy Orlow <jorlow@chromium.org>, public-webapps WG <public-webapps@w3.org>
On Thu, Jan 6, 2011 at 7:37 PM, Felix Halim <felix.halim@gmail.com> wrote:
> On Fri, Jan 7, 2011 at 6:11 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim <felix.halim@gmail.com> wrote:
>>>> 5: Why not make localStorage accessible from the Workers as "read only" ?
>>
>> 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.
>
> What I was suggesting as "read only" is like a "snapshot". So, when
> the main html page spawn a worker, a (consistent) snapshot of the
> localStorage is build at that point of time and passed on to the
> worker. This is the same as creating a worker and sending the first
> message to it (which is the localStorage content, but the difference
> is the snapshot can be more efficient for the main page thread I
> believe).

Ah, that changes things completely! Thanks for clarifying that.

What is the usecase for this?

This is potentially fairly high overhead implementation-wise and so
could slow down localStorage. But I agree it doesn't have the raciness
problems that other suggested solutions have had.

Consider for example the following events:

1. A site stores a 1 MB value in localStorage.foo.
2. The site creates a new worker.
3. The site modifies the value in localStorage.foo to a different 1MB value.

At this point, even the best implementation will have to keep both the
new and the old value in localStorage. Despite the worker not even
using localStorage and thus doesn't care about the old value. It's
certainly implementable, but it'll waste resources.

>> 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);
>> });
>
> Allowing localStorage to be modified inside worker is not safe!

Note that the above intentionally doesn't use localStorage! But rather
a different Storage object which can only be accessed asynchronously
and which doesn't overlap with localStorage.

So long as you only allow asynchronous access the implementation can
ensure that a worker and the main thread doesn't have access to the
storage at the same time. Then it is safe to allow everyone to modify
the storage area.

/ Jonas
Received on Friday, 7 January 2011 03:56:13 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT