On , Jonas Sicking <jo...@sicking.cc> wrote:
On Thu, Jan 6, 2011 at 12:01 PM, Jeremy Orlow <jor...@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.ha...@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.
