[whatwg] localStorage + worker processes

That might work. Is it feasible for user agents to enforce limits on how
long a callback is allowed to run holding the lock? That way workers can't
starve normal pages from accessing their local storage.

-atw

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090321/aeb420c5/attachment-0001.htm>

Received on Saturday, 21 March 2009 09:41:50 UTC