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 <jo...@sicking.cc> wrote: > On Fri, Mar 20, 2009 at 3:10 PM, Aaron Boodman <a...@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 >