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 16:11:23 -0800
Message-ID: <AANLkTik+BnUPDiTwhWbuM5CxKFOu-dOuT43uHZmuYbkg@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
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 3:47 PM, Glenn Maynard <glenn@zewt.org> wrote:
>> 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.

No, implementing the storage mutex is an orders of magnitude harder
than implementing a locking mechanism prevents the callback from
happening in multiple threads at the same time. I'm saying that with
my implementor hat on. They are two very different types of locks. A
major difference is that one is grabbed synchronously and the other
asynchronously.

/ Jonas
Received on Friday, 7 January 2011 00:13:05 GMT

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