Re: [chromium-html5] LocalStorage inside Worker

On Thu, Jan 6, 2011 at 12:01 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> public-webapps is probably the better place for this email
>
> On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim <felix.halim@gmail.com> wrote:
>>
>> I know this has been discussed > 1 year ago:
>>
>> http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html
>>
>> I couldn't find the follow up, so I guess localStorage is still
>> inaccessible from Workers?
>
> Yes.
>
>>
>> I have one other option aside from what mentioned by Jeremy:
>>
>> http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14075.html
>>
>> 5: Why not make localStorage accessible from the Workers as "read only" ?
>>
>> The use case is as following:
>>
>> First, the user in the main window page (who has read/write access to
>> localStorage), dumps a big data to localStorage. Once all data has
>> been set, then the main page spawns Workers. These workers read the
>> data from localStorage, process it, and returns via message passing
>> (as they cannot alter the localStorage value).
>>
>> What are the benefits?
>> 1. No lock, no deadlock, no data race, fast, and efficient (see #2 below).
>> 2. You only set the data once, read by many Worker threads (as opposed
>> to give the big data again and again from the main page to each of the
>> Workers via message).
>> 3. It is very easy to use compared to using IndexedDB (i'm the big
>> proponent in localStorage).
>>
>> Note: I was not following the discussion on the spec, and I don't know
>> if my proposal has been discussed before? or is too late to change
>> now?
>
> I don't think it's too late or has had much discussion any time recently.
>  It's probably worth re-exploring.

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.

Making it readonly unfortunately doesn't help. Consider worker code like:

var x = 0;
if (localStorage.foo < 10) {
  x += localStorage.foo;
}

would you expect x ever being something other than 0 or 1?

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.

/ Jonas

Received on Thursday, 6 January 2011 22:16:08 UTC