[whatwg] localStorage + worker processes

I agree with Jeremy that the spec is currently unimplementable if we give
localStorage access to workers. I'd like to point out that "workers who want
to access localStorage just need to send a message to their main window"
breaks down for persistent workers (where you don't necessarily have an open
browser window) and is pretty wonky for shared workers (you can send a
message to a window, but that window may go away before your message is
processed, so you end up having to build some kind of "send message,
timeout, pick a new window to send it to, etc" message layer).
One alternative I'd like to propose is to remove access to localStorage for
dedicated workers, and give SharedWorkers access to localStorage, but have
that storage be partitioned by the worker name (i.e. the worker can access
it, but it's not shared with web pages or any other workers and so you don't
have any synchronicity issues). I don't see how this would work for
dedicated workers, though, since there's no name to partition storage
access, but they could always fall back to postMessage().

-atw

On Fri, Mar 20, 2009 at 2:19 PM, Oliver Hunt <oliver at apple.com> wrote:

> When discussing this standard we have to recognize that not all
>> browsers actually have a "main thread". Time will tell if more or less
>> browsers of the future will have multi-threaded architectures, but the
>> trend has been for more I think.
>>
>> Any aspects of the spec that asserts or assumes a "main thread" is
>> questionable.
>>
>
> Yes they do -- we're talking about the main thread from the point of view
> of javascript, which is not necessarily the UI thread.
>
> The important thing is that with the current model is that JS on any thread
> may be blocked by js executing in a worker, which leads to a page (in
> effect) locking up -- the UI may still be functional but that particular
> page will have hung.
>
> --Oliver
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090320/66b3fc01/attachment-0001.htm>

Received on Friday, 20 March 2009 14:39:48 UTC