<div>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.</div><div>
<br></div><div>-atw</div><div><br><div class="gmail_quote">On Sat, Mar 21, 2009 at 12:48 AM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Fri, Mar 20, 2009 at 3:10 PM, Aaron Boodman <<a href="mailto:aa@google.com">aa@google.com</a>> wrote:<br>
> I think the best option is to make access to localstorage asynchronous<br>
> for workers. This reduces the amount of time a worker can hold the<br>
> localstore lock so that it shouldn't be a problem for normal pages. It<br>
> sucks to make such a simple and useful API aync though.<br>
<br>
</div></div>As I understand the current API (on main window) to be defined, as<br>
soon as someone accesses the .localStorage property, the<br>
implementation is supposed to acquire a lock. This lock would be held<br>
on to until that script returns to the event loop for that thread.<br>
<br>
So if javascript in another window, running in another thread or<br>
process, tries to access .localStorage for the same origin, the<br>
.localStorage getter would try to acquire the same lock and block<br>
until the first thread releases the lock.<br>
<br>
This could in theory be applied to applied to workers as well. However<br>
as Jeremy points out that could result in the a worker script running<br>
for a very long time blocking the window thread.<br>
<br>
What we could do, is to have an API like<br>
<br>
getLocalStorage(callback);<br>
<br>
This function returns immediately, but will then call the callback<br>
function as soon as the localStorage becomes available and the lock<br>
been acquired. This would always happen asynchronously off the event<br>
loop, which means that once the callback returns the lock is released<br>
again.<br>
<br>
Of course, it would still mean that a window context or worker could<br>
hold on to the lock for an indefinite time, but as long as the asych<br>
getLocalStorage API is used, this means that no thread is blocked,<br>
just that they aren't able to get access to the localStorage.<br>
<br>
So for example, the following code would safely add 1 to the 'foo'<br>
property in localStorage:<br>
<br>
getLocalStorage(function(store) {<br>
  store.foo = parseInt(store.foo, 10) + 1;<br>
});<br>
<br>
Additionally, we would have to define that if the store object passed<br>
to the callback function is accessed outside after the callback has<br>
ended this will throw an exception. If the object is reactivated next<br>
time a callback is entered, or if a new storage object is created also<br>
needs to be defined.<br>
<br>
This new API I believe is good enough to be used both from workers and<br>
window contexts.<br>
<br>
We could even keep the current API implemented in IE8, or we could<br>
just ask people to write a wrapper for IE8 like:<br>
<br>
function getLocalStorage(callback) {<br>
  setTimeout(function() { callback(localStorage); }, 0);<br>
}<br>
<br>
in an implementation that implements correct locking for the<br>
synchronous API, this will even produce the correct locking behavior<br>
for the new API.<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div><br></div>