[whatwg] localStorage + worker processes

As a side note, if we do go with this async lock acquiring, we could
add an API like:

getLockedFeatures(callback, 'localStore', 'cookie');

This would be an asynchronously grab locks to multiple features and
only call the callback once all of them have been acquired. This would
allow computations across data from multiple locations guaranteed to
be in sync. The implementation would be responsible for grabbing the
locks in a consistent order to prevent deadlocks.

/ Jonas

On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> 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
>

Received on Saturday, 21 March 2009 13:57:00 UTC