W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] LocalStorage in workers

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 16 Sep 2009 14:27:41 -0700
Message-ID: <63df84f0909161427q2fdf86a6xa8a0e3f5f1911b59@mail.gmail.com>
On Wed, Sep 16, 2009 at 12:58 PM, Drew Wilson <atwilson at google.com> wrote:
> I'm saying that an async API is overkill and unwieldy if all you need is
> WorkerLocalStorage.
> If you're going to route your localstorage access through an async API
> anyway, then you might as well proxy it to the parent page - there's very
> little advantage to doing it otherwise, other than access to lexically
> scoped resources from within your callback.

Actually, there's a pretty big difference. With the current state of
affairs, if a worker wants to make a computation based on values in
the localStorage, and store the result in localStorage, this is
extremely hard.

For example, say that a worker want to perform the following operation:

localStorage.result = F(localStorage.n);

where F(n) is the n:th value in the Fibonacci sequence.

To do this today the worker would first have to call the main window
to get the localStoreage.n value. It could then calculate the result
of F(localStorage.n). It would then send a message to the main window
to store the result in localStorage.result. However in the meantime
localStorage.n might have changed, which causes an inconsistent state.

So instead the worker has to send both the value of localStorage.n as
well as the result to the window. The window can then check if
localStorage.n has changed. If it has changed, the window has to send
the new value back to the worker, and then the worker has to redo its

This has several problems. It's bug prone since the developer might
not realize the race condition. It's very hard to do correctly. And
even when done correctly risks wasting a lot of cycles.

An alternative solution is to do all calculations in the main window,
which has synchronous access to localStorage. But the whole point of a
worker is to avoid having to do heavy work in the window.

However, with the solution Jeremy proposed, calculating the above
algorithm can be done in the worker after the worker while the worker
is inside the callback and thus have synchronous access to

Say that instead of calculating Fibonacci numbers, we were storing a
database of emails in localStorage, and using a worker to synchronize
that database to a server. In this case it seems extermely complex to
have to communicate asynchronously through the window and deal with
race conditions where the user is modifying the email database at the
same time.

/ Jonas
Received on Wednesday, 16 September 2009 14:27:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC