<div>I'm currently implementing window.localStorage (<a href="http://dev.w3.org/html5/webstorage/#storage" target="_blank">http://dev.w3.org/html5/webstorage/#storage</a>) in Chromium.  While figuring out how to handle concurrency, the issue of integration with workers came up.  The big problem is that there are many valid/good uses of workers that could not be used in conjunction with localStorage.</div>

<div><br></div><div>Before I continue, so that this discussion can be focused, let's just assume that modern day browsers will use the following concurrency model: <span style="font-family:-webkit-sans-serif;font-size:16px"><span style="font-family:arial;font-size:13px">"<span style="font-family:-webkit-sans-serif;font-size:16px;color:rgb(0, 128, 0);font-style:italic;font-weight:bold">the user agent blocks scripts in other browsing contexts when they try to access the same storage area until the <span>event loop</span> running the first script has completed running the task that started that script<span style="color:rgb(0, 0, 0);font-family:arial;font-style:normal;font-weight:normal;font-size:13px">"  (Workers running within a single event loop makes no sense and I really don't want this to turn into a debate on the practicality of optimistic transactions. :-)</span></span></span></span></div>

<div><br></div><div>Anyhow, the very first example in the spec (<a href="http://dev.w3.org/html5/workers/#a-background-number-crunching-worker" target="_blank">http://dev.w3.org/html5/workers/#a-background-number-crunching-worker</a>) shows work that's being done in a infinite loop with postMessage being called when each prime is found.  If you called localStorage anywhere within that loop (say, to periodically save all primes found), you would not be able to safely call window.localStorage in any other worker or the web page.  This is because the "task that started the script" never ends. And this its 'lock' (on other scripts using local storage) will never be released.</div>

<div><br></div><div>That's obviously a somewhat extreme (though I'd argue _not_ contrived) example, but it seems to me that a lot of the work done in workers will be fairly long lived.  Thus presenting serious latency problems for any page or other worker trying to access localStorage.</div>

<div><br></div><div>What is the need for localStorage access within workers?  Technically if someone really needed to access it, they could always have a function in the web page for accessing it and then use postMessage.  In other words, they could build their own ad-hoc async API pretty easily.  Another alternative is to just build an async API into the spec (and remove synchronous access to localStorage).</div>

<div><br></div><div>Thoughts?</div><div><br></div><div>J<br></div>