- From: Drew Wilson <atwilson@google.com>
- Date: Sun, 22 Mar 2009 16:24:56 -0700
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. 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). -atw On Sun, Mar 22, 2009 at 12:07 PM, Michael Nordman <michaeln at google.com>wrote: > > 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. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090322/6f489690/attachment.htm>
Received on Sunday, 22 March 2009 16:24:56 UTC