W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [chromium-html5] LocalStorage inside Worker

From: Joćo Eiras <joao.eiras@gmail.com>
Date: Thu, 06 Jan 2011 22:25:19 -0000
To: "public-webapps WG" <public-webapps@w3.org>
Message-ID: <op.vowq8h1yjz3wb9@coruscant>
On , Jonas Sicking <jonas@sicking.cc> wrote:

> On Thu, Jan 6, 2011 at 12:01 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> public-webapps is probably the better place for this email
>> On Sat, Jan 1, 2011 at 4:22 AM, Felix Halim <felix.halim@gmail.com> wrote:
>>> I know this has been discussed > 1 year ago:
>>> http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14087.html
>>> I couldn't find the follow up, so I guess localStorage is still
>>> inaccessible from Workers?
>> Yes.
>>> I have one other option aside from what mentioned by Jeremy:
>>> http://www.mail-archive.com/whatwg@lists.whatwg.org/msg14075.html
>>> 5: Why not make localStorage accessible from the Workers as "read only" ?
>>> The use case is as following:
>>> First, the user in the main window page (who has read/write access to
>>> localStorage), dumps a big data to localStorage. Once all data has
>>> been set, then the main page spawns Workers. These workers read the
>>> data from localStorage, process it, and returns via message passing
>>> (as they cannot alter the localStorage value).
>>> What are the benefits?
>>> 1. No lock, no deadlock, no data race, fast, and efficient (see #2 below).
>>> 2. You only set the data once, read by many Worker threads (as opposed
>>> to give the big data again and again from the main page to each of the
>>> Workers via message).
>>> 3. It is very easy to use compared to using IndexedDB (i'm the big
>>> proponent in localStorage).
>>> Note: I was not following the discussion on the spec, and I don't know
>>> if my proposal has been discussed before? or is too late to change
>>> now?
>> I don't think it's too late or has had much discussion any time recently.
>>  It's probably worth re-exploring.
> Unfortunately this is not possible. Since localStorage is
> synchronously accessed, if we allowed workers to access it that would
> mean that we no longer have a shared-nothing-message-passing threading
> model. Instead we'd have a shared memory threading model which would
> require locks, mutexes, etc.
> Making it readonly unfortunately doesn't help. Consider worker code like:
> var x = 0;
> if (localStorage.foo < 10) {
>   x += localStorage.foo;
> }
> would you expect x ever being something other than 0 or 1?

Not different from two different tabs/windows running the same code. So the same solution for that case would work for Workers.

Making the API async would make it more hard to use, which is, I believe, one of the design goals of localStorage: to be simple.

If two consecutive reads of the same localStorage value can yield different values, then that's something that developers have to cope with. If they do code that is sensible to that issue, then they can take a snapshot of the storage object, and apply it back later.
Received on Thursday, 6 January 2011 22:26:43 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:29 UTC