[whatwg] localStorage + worker processes

One thing that hasn't been considered yet is some sort of optional hint to
say "I'm done" in terms of accessing localStorage.  Maybe call it
localStorage.checkpoint() or localStroage.commit()?

As far as the browser implemenation is concerned, a call to this function
would be the same as the script ending.  The great thing about this is that
if a developer found one problem location in their code, they could add
it--but it'd be completely optional.

This could be used in conjunction with most of the other ideas already
floating around.

J


On Sun, Mar 22, 2009 at 4:24 PM, Drew Wilson <atwilson at google.com> wrote:

> 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/20090323/a08b5854/attachment-0001.htm>

Received on Monday, 23 March 2009 11:41:59 UTC