Re: [chromium-html5] LocalStorage inside Worker

On Thu, Jan 6, 2011 at 2:25 PM, Joćo Eiras <joao.eiras@gmail.com> wrote:
> 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.

Exposing the web platform to shared memory multithreading is the exact
opposite of 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.

Multithreaded shared memory programming is extremely complex.
Multithreaded shared memory programming without the use of locks is
beyond what I'd ever want to expose anyone to. Much less web
developers.

We've been down this discussion before. Please read the threads on why
workers were designed as a shared-nothing message passing model rather
than a pthreads or similar model.

/ Jonas

Received on Thursday, 6 January 2011 22:46:01 UTC