- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 6 Jan 2011 16:11:23 -0800
- 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 UTC