<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's "this script is taking too long to run" protection) so you won't get starvation. Since worker script never has to re-enter the event loop, this isn't a feasible solution for workers.</div>
<div><br></div><div>That's why I'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'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"><<a href="mailto:michaeln@google.com">michaeln@google.com</a>></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'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>