Re: [chromium-html5] LocalStorage inside Worker

There is always Software Transactional Memory that provides a safe model for
memory shared between threads.

http://en.wikipedia.org/wiki/Software_transactional_memory

This has been used very successfully in Haskell for overcoming threading /
state issues. Combined with Haskells Channels (message queues) it provides
for very elegant multi-threading.


Cheers,
Keean.


On 6 January 2011 22:44, Jonas Sicking <jonas@sicking.cc> wrote:

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