Re: [chromium-html5] LocalStorage inside Worker

On Thu, Jan 6, 2011 at 10:55 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

I'd recommend that the underlying Storage objects that this function
(or functions, for each Storage object) returns should in fact be the
same object (or a thin wrapper, to implement disabling the object
after the callback returns).  For example, getBetterLocalStorage
should use the same underlying storage as localStorage.

If a site wants to guarantee that no asynchronous changes are made,
even on browsers that don't implement the synchronous lock (the lock
that's currently specced), it would need to limit itself to the async
API to access these objects.  On a strictly by-spec browser, mixing
both APIs would be safe; the async callback would never be called
while the storage mutex is held.

This seems much more straightforward to users than having separate
"sync" and "async" storage, and it's much easier to debug than having
a Storage object only accessible from a callback; I regularly
manipulate localStorage from the console.

I'm assuming that if an API like this was adopted, the synchronous
lock for the current localStorage API would remain in the spec.

-- 
Glenn Maynard

Received on Friday, 7 January 2011 04:15:05 UTC