- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 6 Jan 2011 14:11:40 -0800
- To: Jeremy Orlow <jorlow@chromium.org>
- Cc: Felix Halim <felix.halim@gmail.com>, public-webapps WG <public-webapps@w3.org>
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? That said. As I have suggested before (don't remember if it was here or on the whatwg list), if we create a new version of localStorage, where you can only get a reference to the localStorage object asynchronously, then we should be fine. So something like: var s; getBetterStorage(function(storage) { storage.foo += storage.bar; storage.baz = "hello world"; storage.text = "she sells sea schells by the sea shore"; s = storage; setTimeout("runlater", 10); }); function runlater() { s.foo = "bar"; // throws an exception } would work fine, both in workers and outside them. It would also remove the racyness that many localStorage implementations have since they don't implement the storage mutex. / Jonas
Received on Thursday, 6 January 2011 22:16:08 UTC