[whatwg] localStorage + worker processes

[Michael Nordman]

On Mon, Mar 23, 2009 at 11:41 AM, Jeremy Orlow <jorlow at google.com> wrote:

> 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.
>

If we're stuck with the "implicit" lock (somewhat insidious in my "radical"
view:), agree an explicit means of releasing that lock would be nice....
.Unlock() maybe?


>
> 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/b2bb8e5f/attachment.htm>