<div>If you deny workers, you can enforce exclusive access to localStorage by applying a lock that extends from the first access of localStorage until the script re-enters the event loop. Page script is guaranteed to re-enter the event loop fairly quickly (lest it trigger the browser&#39;s &quot;this script is taking too long to run&quot; protection) so you won&#39;t get starvation. Since worker script never has to re-enter the event loop, this isn&#39;t a feasible solution for workers.</div>
<div><br></div><div>That&#39;s why I&#39;m proposing that the most reasonable implementation is just to have a simple lock like I describe above, and then either deny access to localStorage to dedicated workers (shared workers can silo the storage as I described previously), or else just enforce a limit to how long workers can hold the localStorage lock (if they hold it beyond some period, they get terminated just like page script that doesn&#39;t re-enter the event loop).</div>
<div><br></div><div>-atw<br><br><div class="gmail_quote">On Sun, Mar 22, 2009 at 12:07 PM, Michael Nordman <span dir="ltr">&lt;<a href="mailto:michaeln@google.com">michaeln@google.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><div class="gmail_quote"><div><div class="h5"><div>I don&#39;t see how denying workers solves the problem. In a multi-threaded browser, this has to be resolved reasonably even in the absence of workers. <br></div></div>
</div>
<div><br></div><div><br></div></div>
</blockquote></div><br></div>