W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] localStorage + worker processes

From: Drew Wilson <atwilson@google.com>
Date: Sun, 22 Mar 2009 16:24:56 -0700
Message-ID: <f965ae410903221624i448501d0l9cadd4e2fb0ba9aa@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT