[whatwg] localStorage + worker processes

[Jonas Sicking]

On Fri, Mar 20, 2009 at 3:10 PM, Aaron Boodman <aa at google.com> wrote:
> I think the best option is to make access to localstorage asynchronous
> for workers. This reduces the amount of time a worker can hold the
> localstore lock so that it shouldn't be a problem for normal pages. It
> sucks to make such a simple and useful API aync though.

As I understand the current API (on main window) to be defined, as
soon as someone accesses the .localStorage property, the
implementation is supposed to acquire a lock. This lock would be held
on to until that script returns to the event loop for that thread.

So if javascript in another window, running in another thread or
process, tries to access .localStorage for the same origin, the
.localStorage getter would try to acquire the same lock and block
until the first thread releases the lock.

This could in theory be applied to applied to workers as well. However
as Jeremy points out that could result in the a worker script running
for a very long time blocking the window thread.

What we could do, is to have an API like

getLocalStorage(callback);

This function returns immediately, but will then call the callback
function as soon as the localStorage becomes available and the lock
been acquired. This would always happen asynchronously off the event
loop, which means that once the callback returns the lock is released
again.

Of course, it would still mean that a window context or worker could
hold on to the lock for an indefinite time, but as long as the asych
getLocalStorage API is used, this means that no thread is blocked,
just that they aren't able to get access to the localStorage.

So for example, the following code would safely add 1 to the 'foo'
property in localStorage:

getLocalStorage(function(store) {
  store.foo = parseInt(store.foo, 10) + 1;
});

Additionally, we would have to define that if the store object passed
to the callback function is accessed outside after the callback has
ended this will throw an exception. If the object is reactivated next
time a callback is entered, or if a new storage object is created also
needs to be defined.

This new API I believe is good enough to be used both from workers and
window contexts.

We could even keep the current API implemented in IE8, or we could
just ask people to write a wrapper for IE8 like:

function getLocalStorage(callback) {
  setTimeout(function() { callback(localStorage); }, 0);
}

in an implementation that implements correct locking for the
synchronous API, this will even produce the correct locking behavior
for the new API.

/ Jonas